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PREFACE 



Since Intel Introduced the ISBC 80/10 Single Board Computer In early 1976, the family of Intel OEM Microcomputer 
Systems has grown rapidly. Original equipment manufacturers and volume end-users alike have responded to the con- 
cept originated by Intel of having all the functions of a computer — central processing unit, memory, input-output and 
system expansion capability — present on one printed circuit board. 

The capabilities of a single board computer have been enhanced by the creation of the industry-standard MULTIBUS 
system bus. System expansion boards have been introduced for memory, serial I/O and parallel I/O expansion, as well 
as analog I/O, DMA controllers and peripheral controllers. A unique feature of the MULTIBUS architecture, however, is 
its capability to support multiple single board computers. This capability permits sophisticated multiprocessing con- 
figurations using standard off-the-shelf 8-bit and 16-blt single board computers. Powerful software tools like the 
RMX/80 Real-Time Multitasking Executive, the FORTRAN run-time package and the resident BASIC interpreter also 
are key members of the ISBC product family. They provide users with the tools for quick implementations of simple or 
complex systems. The recently introduced ICS product line provides chassis and signal conditioning/termination 
strips as well as board level products which were developed specifically for industrial users. 

This application manual is divided into three sections: iSBC Hardware, ISBC Software and iCS Products. It contains all 
of the current application notes, reliability reports, magazine articles and professional journal reprints on the products 
of the Intel ISBC product family. We have compiled all of this information into a single publication for your conven- 
ience. Please contact us with your questions, comments, and suggestions on how we may provide you with useful in- 
formation on our products. 

INTEL CORPORATION 

OEM Microcomputer Systems 
Applications Engineering 
Hillsboro, Oregon 97123 
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1 iSBC Hardware 



iSBC HARDWARE 



INTRODUCTION 

The current hardware products available in the iSBC product line include six single board computers and over 30 ex- 
pansion boards and accessories. Each Intel single board computer provides all the resources of a full computer (i.e., 
CPU, read/write memory, read only, parallel I/O and serial I/O) on a single printed circuit board. The iSBC 655 and iSBC 
660 chassis extend these capabilities into low cost, fully packaged RETMA rack-mountable computers. The Intel 
single board computers are supported by a complete line of memory, parallel and serial I/O, digital I/O and analog I/O 
expansion boards, and peripheral and DMA controllers, all of which are compatible with the Industry-standard micro- 
computer bus — the Intel MULTIBUS system bus. 

This section contains application notes and magazine articles covering the architectural features of the ISBC product 
family, the ISBC 80/10A, ISBC 80/30, and iSBC 86/12A Single Board Computers, and the ISBC 544 Intelligent Slave 
Board. In addition, reliability reports for the iSBC 80/10A and ISBC 86/12A boards are included. 

TABLE OF CONTENTS 

AP-26 ISBC 80/10A-SYSTEM 80/10 Single Board Computer Applications 1-3 

AP-28A Intel MULTIBUS Interfacing 1-45 

AP-43 Using the ISBC 957 Execution Vehicle for Executing 8086 Program Code 1-79 

AP-53 Using the ISBC 544 Intelligent Communications Controller .1-111 

RR-17 Intel SBC 80/10 Single Board Computer .1-175 

RR-23 Intel ISBC 86/12A Single Board Computer 1-187 

AR-48 Reduce your /iC-based system design time by using single board microcomputers 1-195 

AR-55 Design Motivations for Multiple Processing Microcomputer Systems. 1-207 

AR-65 Triple-bus architecture on a single board microcomputer. 1-217 

AR-69 Dual-port RAM Hikes Throughput Input-Output Controller Board 1-225 

AR-72 16-bit Single Board Computer Maintains 8-bit Family Ties .1-233 
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INTRODUCTION 

The recent entry of the single board computer into 
the broad field of electronic applications is sub- 
stantiating the bilHng as a "super component". 
Single board computers provide a solution to 
several problems that have not been solved by the 
use of conventional computers: cost, size, and 
design specialization. 

Many potential microcomputer applications have 
been overlooked because of the design tasks 
required to build a microcomputer system. These 
tasks traditionally include interfacing of the system 
clock, read/write memory, I/O ports and drivers, 
serial communications interface, bus control logic 
and drivers. Intel's iSBC 80/lOA enables the design 
engineer to concentrate on the application of 
microcomputers, rather than on implementation 
details. 

This application note begins with an overviev^ of 
the Intel® iSBC 80/lOA. Readers who are famihar 
with the iSBC 80/lOA may choose to skip to the 
applications section, which describes the following 
typical iSBC 80/lOA appHcations: 

• The iSBC 80/lOA used for instrumentation 
control of a Fluke 8375 Digital Multimeter. 

• The iSBC 80/lOA used as a SCAD A Terminal 
in a communication appHcation. 

• The iSBC 80/lOA used for temperature moni- 
toring in a process control application. 

• The iSBC 80/lOA used as an interrupt driven 
device controller for a Centronics printer. 



Each example shows the user program and hard- 
ware required for the application. The program 
listings are interspersed with the text describing 
the application. Both 8080 Macro Assembly 
Language and Intel's PL/M-80 are used in the 
examples. 

The software was developed on an Intel® Micro- 
computer Development System (MDS). The MDS 
provided the tools necessary to edit, assemble or 
compile, link and locate the appHcation software. 
Hardware development was facilitated by the use 
of Intel's In-Circuit Emulator (ICE 80). For further 
information regarding the Microcomputer Develop- 
ment System, the reader is referred to the pubUca- 
tions Hsted at the beginning of this appHcation 
note. 

OVERVIEW 

The iSBC 80/lOA is a member of Intel's complete 
line of OEM computer systems which take fuU 
advantage of Intel's LSI technology to provide 
economical, self-contained computer based solu- 
tions for OEM appHcations. The iSBC 80/lOA is a 
complete computer system on a single 6.75-by-12 
inch printed circuit card. A block diagram of the 
iSBC 80/lOA is shown in Figure 1. 

Intel's powerful 8-bit n-channel MOS 8080A CPU, 
fabricated on a single LSI chip, is the central pro- 
cessor for the iSBC 80/lOA. The 8080A contains 
six 8-bit general purpose registers and an accumu- 
lator. The six general purpose registers may be 
addressed individually or in pairs, providing both 
single and double precision operators. 
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1. Interrupts originating from the Programmable Communications Interface and Programmable Peripheral Interface are jumper selectable. 

Figure 1. iSBC 80/1 OA Block Diagram 



1-5 



The 8080A has a 1 6-bit program counter which 
allows direct addressing of up to 64K bytes of 
memory. An external stack, located within any 
portion of read/write memory, may be used as a 
last in/first out stack to store the contents of the 
program counter, flags, accumulator and all of the 
six general purpose registers. A 16-bit stack pointer 
addresses the external stack. This provides sub- 
routine nesting that is bounded only by memory 
size. 

The iSBC 80/lOA contains IK bytes of read/ 
write memory using Intel's low power static RAM. 
All on board RAM read and write operations are 
performed at maximum processor speed. Four 
sockets for up to 8K bytes of non-volatile read- 
only memory are provided on the board. Read- 
only memory may be added in IK byte increments 
(up to 4K total) using Intel® 8708 erasable and 
electrically reprogrammable ROMs (EPROMs) 
or Intel 8308 masked ROMs. Optionally, if more 
than 4K bytes are required, read only memory may 
be added in 2K byte increments (up to 8K total) 
using Intel® 2716 EPROMs or 2316E masked 
ROMs. All on-board ROM or EPROM read opera- 
tions are performed at maximum processor speed. 

The iSBC 80/lOA contains 48 programmable para- 
llel I/O lines implemented using two Intel® 8255 
Programmable Peripheral Interfaces. The system 
software is used to configure the I/O Hnes in any 
combination of unidirectional input/output, and 
bidirectional ports indicated in Table I. Therefore, 
the I/O interface may be customized to meet 
specific peripheral requirements. To support the 
large number of possible I/O configurations, 
sockets are provided for interchangeable I/O line 
drivers and terminators. Hence, the I/O interface 



provides the appropriate combination of optional 
line drivers and terminators to allow the required 
sink current, polarity, and drive/termination 
characteristics for each apphcation. The 48 pro- 
grammable I/O Unes and signal ground hnes are 
brought out to two 50-pin edge connectors that 
mate with flat, round, or woven cable. 

A programmable communications interface using 
Intel's 8251 Universal Synchronous/ Asynchronous 
Receiver/Transmitter (USART) is contained on the 
iSBC 80/lOA. A jumper selectable baud rate 
generator provides the 8251 with all common 
communication frequencies. The 8251 can be pro- 
grammed by the user's system software to select 
the desired asynchronous or synchronous serial 
data transmission technique (including IBM Bi- 
sync). The mode of operation (synchronous or 
asynchronous), data format, control character 
format, parity, and asynchronous transmission 
rate are all under program control. The 8251 pro- 
vides full duplex, double buffered transmission and 
receive capability. Parity, overrun, and framing 
error detection circuits are all incorporated in the 
8251. The inclusion of jumper selectable TTY or 
EIA RS232C compatible interfaces on the board, 
in conjunction with the 8251, provide a direct 
interface to teletypes, CRTs, asynchronous and 
synchronous modems, and other RS232C com- 
patible devices. The RS232C or TTY command 
Unes, serial data Unes, and signal ground Unes are 
brought out to a 25-pin edge connector that mates 
With RS232C compatible flat, round, or woven 
cable. 

Interrupt requests may originate from six sources. 
Two from the 8255's, two from the 8251 and two 
from user designated peripheral devices. 



TABLE 1 INPUT/OUTPUT PORT MODES OF OPERATION 



PORT 


NO. OF LINES 


MODE OF OPERATION I 


UNIDIRECTIONAL 


BIDIRECTIONAL 


CONTROL 


INPUT 


OUTPUT 


UNLATCHED 


LATCHED & 
STROBED 


LATCHED 


LATCHED & 
STROBED 


1 


8 


X 


X 


X 


X 


X 




2 


8 


X 


X 


X 


X 






3 


8 


X 




X 






xi 


4 


8 


X 




X 








5 


8 


X 




X 








6 


4 


X 




X 










4 


X 




X 









1. Note: Port 3 must be used as a control port when either Port 1 or Port 2 are used as a latched and strobed Input or a latched and 
strobed output or Port 1 is used as a bidirectional port. 
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The 8255's can generate interrupts when a byte of 
information is ready to be transferred to the CPU 
(i.e., input buffer full) or a byte of information has 
been transferred to a peripheral device (i.e., output 
buffer is empty). 

The 8251 can generate interrupts when a character 
is ready to be transferred to the CPU (i.e., receive 
channel buffer is full) or a character is ready to be 
transmitted (i.e., transmit channel data buffer is 
empty). 

The user designated peripheral devices can generate 
two interrupts: one via the system bus and the 
other via the I/O edge connector. 

The two interrupts from the 8255's and the two 
interrupts from the 8251 are all individually mask- 
able under program control. The six interrupt 
request lines share a single CPU interrupt level. 
When an interrupt request is recognized, a RE- 
START 7 instruction is generated. The processor 
responds by suspending program execution and 
making a subroutine call to a user defined interrupt 
service routine originating at location 38 (Hexa- 
decimal). 

iSBC 80/lOA memory and I/O capacity may be 
increased by adding standard Intel memory and 
I/O boards. Modular expandable backplanes and 
card cages, each with a four-board capacity, are 
available to support multi-board systems. 

The development cycle of iSBC 80/lOA based 
products may be significantly reduced using the 
Intellec Microcomputer Development System. The 
resident macro-assembler, PL/M-80 compiler, text 
editor, and system monitor greatly simpHfy the 
design, development, and debug of user designed 
iSBC 80/lOA system software. A diskette-based 
system allows programs to be loaded, assembled, 
edited, and executed faster than using conventional 
paper tape, card, or cassette peripherals. A unique 
In-Circuit Emulator (ICE 80) provides the capa- 
biUty of developing and debugging software 
directly on the iSBC 80/lOA. 

iSBC CONFIGURATION OPTIONS 

The iSBC 80/10 provides the user with a powerful 
and flexible I/O capabiUty for both parallel and 
serial transfers. This section discusses the user 
programmable and jumper-selectable options, and 
bus interfacing. 

SERIAL I/O OPTIONS 

The serial I/O interface, using Intel's 8251 USART, 
provides a serial data communications channel that 
can be programmed to operate with most of the 



current serial data transmission protocols. There 
are three general areas of serial I/O options: 

1. choice of interface type, RS232C or current 
loop, 

2. baud rate and program-selectable mode 
options, 

3. choice of an interrupt mechanism. 

The user has the choice, through jumper connec- 
tions, of configuring the serial I/O logic to present 
either an RS232C or a 20 mA current loop inter- 
face to an external device. If an RS232C interface 
is used, the 8251 can assume the role of a "data 
set" or a "data processing terminal". This enables 
the serial interface to be connected to different 
devices such as modems and computer terminals. 

There are two factors which enter into the choice 
of baud rate. They are the actual clock frequency 
used to drive the transmit/receive clocks on the 
8251 and the baud rate factor selected by a pro- 
grammable mode instruction control word output 
by the processor to the 8251. The baud rate factor 
is used to effectively divide the 8251 transmit and 
receive clocks by 1 , 1 6 or 64. During normal oper- 
ation a factor of 16 is selected for asynchronous 
transmissions from 9.6K to 300 baud. A factor of 
64 must be used to achieve a baud rate of 1 10. The 
baud rate factor is only appHcable to asynchronous 
transmission, as all synchronous transmission is 
done with an imphed factor of one. 

Before beginning serial I/O operations, the 8251 
must be program-initialized to support the desired 
mode of operation. The CPU initializes the 8251 
by issuing a set of control bytes to the USART 
device. These control words specify: 

• synchronous or asynchronous operation 

• baud rate factor 

• character length 

• number of stop bits 

• even/odd parity 

• parity/no parity 

Refer to the iSBC 80/10 and iSBC 80/lOA Single 
Board Computer Hardware Reference Manual or 
the "8251 Apphcation Note" for details on the 
control words used to direct the operation of the 
8251. 

The serial I/O logic can be configured with differ- 
ent forms of interrupt request mechanisms. By 
connecting a jumper, the user can allow the 825 1's 
Receiver Ready output to generate an interrupt 
request. The Receiver Ready output goes high 
whenever the Receiver Enable bit of the command 
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word has been set and the 8251 contains a charac- 
ter that is ready to be input to the CPU. The user 
can also choose to have the 825 1's Transmitter 
Ready or Transmitter Empty output activate the 
interrupt request. The Transmitter Empty goes 
high when the 8251 has no characters to transmit. 
Transmitter Ready is high when the 8251 is ready 
to accept a character from the CPU. Both Trans- 
mitter Empty and Transmitter Ready are enabled 
by setting the Transmit Enable bit of the command 
word. Upon receiving an interrupt, the program 
can determine the actual condition which is 
responsible for the interrupt by reading the status 
of the 8251 device. 

PARALLEL I/O OPTIONS 

The parallel I/O interface consists of six 8-bit I/O 
ports implemented with two Intel 8255 Program- 
mable Peripheral Interface devices. Eight lines 
already have a bidirectional driver and termination 
network permanently installed. The remaining 40 
Unes are uncommitted. Sockets are provided for 
the installation of active driver networks or passive 
termination networks as required to meet the 
specific needs of the user system. 

The primary considerations in determining how to 
use each of the six I/O ports are: 

1 . choice of operating mode, 

2. direction of data flow (input, output or 
bidirectional), 

3. selection of interrupt mechanism, 

4. choice of driver/termination networks for 
the port's data path. 

Operating Modes. There are three basic operating 
modes that can be selected by the system software. 
The modes of operation will be described here in 
general terms, leaving it to the reader to obtain 
details from the iSBC 80/10 and iSBC 80/lOA 
Single Board Computer Hardware Reference 
Manual or the "8255 Apphcation Note." 

Mode is a basic input/output functional con- 
figuration which provides simple input and out- 
put operations. No "handshaking" is required, 
data is simply written to or read from a specified 
port. The outputs are latched and the inputs are 
unlatched. 

Mode 1 is a strobed input/output functional 
configuration which provides a means for trans- 
ferring I/O data to or from a specified port in 
conjunction with strobes or handshaking signals. 
The outputs are latched and are accompanied by 



an output control line which indicates that the 
processor has loaded the output port with a data 
byte. The input data is latched when accompa- 
nied by its externally operated control signal. 

Mode 2 is a strobed bidirectional bus input/ 
output functional configuration which provides 
a means for communicating with a peripheral 
device or structure on a single 8-bit bus for both 
transmitting and receiving data. Handshaking 
signals are provided to maintain proper bus flow 
discipline in a manner similar to mode 1 . 

Data Flow Direction. In addition to the choice of 
operating mode, the user may also specify the 
direction of data flow, input or output from the 
8255's. At the time of RESET, the 8255's are 
configured into the input mode until altered by a 
control word directed to the control word register. 
When an output mode control word is received, 
all of the data bits are set to the low output state. 

Interrupt Mechanism. When the 8255 is pro- 
grammed to operate in mode 1 or mode 2, control 
signals are provided that can be used as interrupt 
request inputs to the CPU. The interrupt request 
signals, generated from one of the ports (port C), 
can be inhibited or enabled by setting or resetting 
the associated interrupt enable flip-flop, using the 
bit set/reset function of port C. This function 
allows the programmer to mask the interrupts from 
specific I/O devices without affecting any other 
device in the interrupt structure. 

Driver /Termination Networks. Depending on the 
direction of data flow, the user will select the 
appropriate TTL line drivers and Intel terminators 
that are compatible with the I/O driver/terminator 
sockets on the iSBC 80/ 10 A. The list of suitable 
line drivers includes those with inverting, non- 
inverting, and open collector characteristics. 
There are two types of terminators: a 220-ohm/ 
330-ohm divider or a IK ohm pull-up. 

BUS INTERFACING 

The system bus interface logic consists of three 
general groups of circuitry : 

1. gates that accept the various bus control 
signals, the interrupt request lines, and the 
ready indications, and then apply these 
signals to the CPU logic elements, 

2. the system bus drivers, 

3. the failsafe circuitry which generates an 
acknowledgment during interrupt sequences 
and during those cycles in which an ac- 
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knowledgment is not returned because a 
non-existent device was inadvertently ad- 
dressed. 

Bus Interface Signals. The following paragraphs 
describe portions of the system bus interfacing 
logic relevant to interfacing a user device to the 
iSBC 80/ 10 A. (Note: Whenever a signal is active- 
low, its mnemonic is followed by a slash; for 
example, MRDC/ means that the level on that line 
will be low when the memory read command 
is true.) 

BCLK/ - Bus clock; used to synchronize bus 
control circuits on all master modules. BCLK/ 
has a frequency of 9.216 MHz. BCLK/ may 
be slowed, stopped or single stepped, if 
desired. 

INIT/ — Initiahzation signal; resets the entire 
system to a known internal state. 

BPRN — Bus priority input signal; indicates to 
the iSBC 80/lOA that a higher priority mas- 
ter module is requesting use of the system 
bus. BPRN suspends the processing activity 
and drivers of the iSBC 80/10A until the sig- 
nal goes low. 

BUSY/ — Bus busy signal; indicates that the bus 
is currently in use. BUSY/ prevents all other 
master modules from gaining control of the 
bus. BUSY/ is driven by the HLDA/ output 
from the iSBC 80/lOA in response to a 
BPRN input. It indicates that the bus is 
available. 

MRDC/ — Memory read command; indicates 
that the address of a memory location has 
been placed on the system address lines and 
specifies that the contents of the addressed 
location are to be read and placed on the sys- 
tem data bus. 

MWTC/ — Memory write command; indicates 
that the address of a memory location has 
been placed on the system address lines and 
that a data word has been placed on the 
system data bus. MWTC/ specifies that the 
data word is to be written into the addressed 
memory location. 

lORC/ — I/O read command; indicates that the 
address of an input port has been placed on 
the system address bus and that the data at 
that input port is to be read and placed on the 
system data bus. 

lOWC/ — I/O write command; indicates that the 
address of an output port has been placed on 
the system address bus and that the contents 



of the system data bus are to be output to 
the addressed port. 

XACK/ — Transfer acknowledge signal; the 
required response of an external memory 
location or I/O port which indicates that the 
specified read/write operation has been com- 
pleted (that is, data has been placed on, or 
accepted from, the system data bus lines). 

AACK/ - An advance acknowledge, in response 
to a memory read or write command, that 
allows the memory to complete the specified 
operation without requirii^g the CPU to wait. 

CCLK/ - Constant clock; provides a clock signal 
of constant frequency (9.216 MHz) for use by 
optional memory and I/O expansion boards. 
The same signal is used to drive both CCLK/ 
and BCLK/. 

INTRl/ — Externally generated interrupt re- 
quest. 

ADRO/-ADRF/ - 16 Address lines; used to 
transmit the address of the memory location 
or I/O port to be accessed. ADRF/ is the most 
significant bit. 

DATO/— DAT7/ — Bidirectional data lines; used 
to transmit/receive information to/from a 
memory location or I/O port. DAT7/ is the 
most significant bit. 

Bus Acknowledges. Further distinction between 
transfer acknowledge (XACK/) and advance 
acknowledge (AACK/) is required. All external 
memory and I/O transfer requests must return 
XACK/ to the iSBC 80/lOA (even if AACK/ is also 
returned). XACK/ indicates that data has been 
placed on (read command) or accepted from (write 
command) the system data bus lines. AACK/ is an 
advance acknowledge in response to a memory or 
I/O port command. It has been provided because 
the 8080A samples the ready line before valid data 
is required on the bus. If this condition is properly 
anticipated, AACK/ can be returned before the 
data is actually read, thus allowing an earlier opera- 
tion to be completed. AACK/ should be used only 
with a thorough understanding of the additional 
information provided in the iSBC 80/10 and 
iSBC 80/lOA Single Board Computer Hardware 
Reference Manual. DMA Transfers. An external 
device can make DMA transfers to or from RAM 
expansion boards. The transfer is coordinated 
with the iSBC 80/lOA by means of two bus 
signals: bus priority input (BPRN) and bus busy 
(BUSY/). The first step in making a DMA transfer 
is to obtain control of the system bus. This is 
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achieved by asserting BRPN to the iSBC 80/lOA 
and then waiting until the iSBC 80/lOA returns 
BUSY/, indicating that it has relinquished control 
of the system bus. When this step is completed the 
external device may proceed with its DMA trans- 
fers until it is finished. At that time BPRN should 
be removed to allow the iSBC 80/lOA to regain 
control of the system bus. It should be noted 
that the iSBC 80/lOA is placed in a hold state 
when it does not have control of the system 
bus. 

APPLICATIONS 

The iSBC 80/lOA may be applied to a wide variety 
of appHcations. Specific applications in four areas 
are presented in this appHcation note. They are 
presented to illustrate a broad spectrum of single 
board computer capabihties and to demonstrate 
the use of various system features. 

INSTRUMENTATION 

Microprocessors have been used in instrumentation 
for many tasks ranging from handling simple inter- 
face functions to control of the analog to digital 
conversion process. The use of a single board com- 
puter can further serve in the application of 
instruments themselves to laboratory or process 
control environments. It is quite often necessary in 
these applications to control instrumentation 
remotely. A number of rather expensive minicom- 
puter-controlled solutions now exist on the market 
as automatic test equipment (ATE) systerris. The 
iSBC 80/lOA presents itself as a cost effective solu- 
tion in situations where the larger ATE systems are 
beyond economic justification. 

The iSBC 80/lOA can be the sole CPU element 
in the system, providing instrumentation control 
and computational capabiUty; or it can supple- 
ment a larger host CPU by handhng distributed 
processing requirements. 

Instrumentation Control Application Example 

Most instruments such as DVMs, counters, data 
loggers, synthesizers, etc., have optional data out- 
put units (DOUs) and/or remote control units 
(RCUs). It is particularly time consuming to inter- 
face each instrument's DOU/RCU with custom- 
digital logic. Until the recent IEEE-488 interface 
standard, there was Httle in common from one 
interface to the next. The parallel I/O lines of the 
iSBC 80/lOA provide a common interface element 
that can be adapted to a majority of the DOUs and 
RCUs available today by means of software. 
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Figure 2. Interface Block Diagram 



This instrumentation control application shows 
how the iSBC 80/lOA has been used to control and 
read the data from the data output unit (DOU) of 
a Fluke 8375 Digital Multimeter. 

Interfacing the iSBC 80/lOA to the Fluke 8375 
DOU has been accompHshed through the use of 
three parallel I/O ports shown in Figure 2. An 8-bit 
port has been used to read input data from the 
Fluke 8375 DOU. Another 8-bit port has been 
used to control the multiplexing of data from the 
DOU to the iSBC 80/lOA. And, an 8-bit port has 
been used to provide the required control and 
monitoring of the following DOU functions: 
busy flag, sample sync flag, timeout enable, exter- 
nal trigger and trigger inhibit. 
The following listing contains a complete program 
to provide the necessary interface control func- 
tions as well as an exercise program. The program 
hsting is interspersed with text that is used to 
clarify the elements of the program. 



INSTRUMENTATION CONTROL APPLICATION 

FLUKE 8375 DIGITAL MULTIMETER 

DATA OUTPUT UNIT (DOU) CONTROLLER 



The CSEG directs the ISIS-II 8080 Assembler to 
generate a relocatable code segment. Relocatable 
code can later be placed at any memory address by 
Intel's LOCATE program. This lets you write your 
program without worrying about the appHcation's 
final memory configuration. 
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Equate Table. The following table is used to give 
symbolic names to the binary I/O port addresses. 
The names used later in the program increase 
readability. 



EQUATE TABLE 



18 CWH EQU OEBH ; 8255 #2 CONTROL WORD REGISTER 

19 DATIN EQU 0E8H ; DECADE PAIR DATA INPUT PORT 

20 STB EQU 0E9H ; STROBE OUTPUT PORT 

21 FLG EQU OEAH ; FLAG INPUT PORT 

22 TRG EQU OEAH ; TRIGGER OUTPUT PORT 



Observing the schematic for the iSBC 80/lOA - 
Fluke 8375 DOU (Figure 3), it can be seen that the 
8255 #2 should be configured through the use of 
the mode control word as: 

Port 4 (A) Mode Input 

Port 5 (B) Mode Output 

Port 6 (C) Bits PC2-PC0 Output 

Port 6(C) BitsPC5-PC4 Input 

The following mode control word is used: 



The exercise program uses some of the subroutines 
provided in the iSBC 80/lOA System Monitor 
PROMs. The addresses of the subroutines are 
included in the equate table. 



25 








26 ; 








27 GETCri 


EQU 


0220H 


; GET CONSOLE INPUT, MASK OFF PARITlf 


28 CO 


EQU 


01E8H 


; CONSOLE OUTPUT 


29 CROUT 


EQU 


01F3H 


; PRINT <CR><LF> 


30 NMOUT 


EQU 


02C2H 


; DISPLAY BYTE IN ACCUM 


31 ; 








32 









I Dy I Dg I D5 I D4 I Da I 02 I Dl I Dp I 



Port C Bits PC0-PC2 Output = 



Port B Output = 



Port B Mode = 



Port C Bits PC4-PC5 Input = 



Port A Input = 1 



Port A Mode = 00 



Opcode Mode Set = 1 



Mode Control Word = 1001 1000 Binary = 98H 



The use of the iSBC 80/lOA parallel I/O ports 
requires that the mode of operation be defined for 
each port. This is typically done by an initiaUza- 
tion subroutine executed when the iSBC 80/lOA 
is powered up or reset. 

8255 Control Word. When the opcode field (bit 7) 
of a control word directed to an 8255 is equal to 
one, the control word is interpreted as a mode 
definition control word. The mode definition 
control word format is shown below: 

CONTROL WORD 



PORT C (LOWER - PC3-PC0) 
1 = INPUT 
= OUTPUT 



PORTB 
1 = INPUT 
0= OUTPUT 



MODE SELECTION 

= MODE0 

1 = MODE 1 



PORT C (UPPER - PC7-PC4) 
1 = INPUT 
= OUTPUT 



PORTA 
1 = INPUT 
= OUTPUT 



MODE SELECTION 

00 = MODE 

01 =MODE 1 
IX = MODE 2 



/ OPCODE \y 

•►I 1 = MODE SET I 



33 

34 ; 

35 ; *** 8255 #2 INITIALIZATION SUBROUTINE 

36 ; 



37 INIT: 

38 

39 



; LD MODE CONTROL WORD 
■; OUTPUT TO 8255#2 CNTL WD REG 



This coding loads the mode control word into the 
8255 #2 control word register. Additional initial- 
ization code is required to set the strobe and 
trigger output ports to an inactive state. The sche- 
matic shows that inverting drivers have been used 
for both the strobes and the trigger. When a com- 
mand is issued to place port 5 (B) into the output 
mode, bits PB7-PB0 are set to the low output 
state. Because the low outputs are then inverted 
and used as strobes to the Fluke 8375, they must 
then be disabled. The initialization subroutine 
concludes by disabUng the strobes and trigger. The 
strobes are signals to the DOU which enable its 
drivers to send data to the iSBC 80/lOA. The trig- 
ger is a signal to the DOU that the Fluke 8375 
should take a reading. 



H4 


MVI 


A.OFFH 


; LD MASK TO: 


45 


OUT 


STB 


; DISABLE STROBES 


46 
47 


OUT 
RET 


TRG 


; DISABLE TRIGGER 



External Trigger Control Two subroutines are 
implemented to enable and disable the external 
trigger mode of the instrument. These subroutines 
use the bit set/reset capability of the 8255 to inde- 
pendently set or reset three control Hnes of the 
Fluke 8375 DOU. 
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When the opcode field (bit 7) of an 8255 control 
word equals zero, the control word is a port 6 (C) 
bit set/reset command word. 

The bit set/reset control word format is shown 
below: 



CONTROL WORD 



3 



SET/RESET FLAG 



BIT SELECT 



NOT USED SET TO 000 



BIT 5 
BIT 6 
BIT7 



/I 



^ 



= BIT SET/RESET 



The following example demonstrates how the port 
6 (C) bit set/reset control word is constructed to 
disable the Fluke 8375 external trigger. Note from 
the schematic (Figure 3) that port 6 (C) bit con- 
trols the inhibit external trigger Une. 



|D7|D6|D5|D4|D3|D2|Di|d7] 

[Set Bit = 



Bit Select = 000 (Binary) 



Not Used = 000 (Binary) 



Bit Set/Reset Opcode = 



The control word for set Port C bit is 0000 0001 Binary = 01 H 



t ENABLE EXTERNAL TRIGGER SUBROUTINE * 



55 MVI A.OOOOOOOOB 


; LD RESET BIT CONTROL WORD 


56 OUT CWR 


; OUTPUT TO 8255#2 CNTL WD REG 


57 RET 




56 ; 




59 ; ••• DISABLE EXTERNAL TRIGGER 


SUBROUTINE »•• 


60 ; 




61 DTRIG: 




62 MVI A, 00000001 B 


; LD SET BIT CONTROL WORD 


63 OUT CWR 


; OUTPUT TO 8255#2 CNTL WD REG 


614 RET 




65 ; 





Subroutines to enable and disable the timeouts are 
written in an analogous fashion. The timeout 
enable line is controlled by port 6 (C) bit 2. 



69 ; »" 


ENABLE TIMEOUTS SUBROUTINE »*» 


70 ; 




71 EPOS: 




72 


MVI A.OOOOOIOIB ; LD SET BIT 2 CONTROL WORD 


73 


OUT CWR ; OUTPUT TO 8255#2 CNTL WD REG 


74 


RET 


75 ; 




76 ; "• 


DISABLE TIMEOUTS SUBROUTINE *»• 



; LD RESET BIT 2 CONTROL WORD 
; OUTPUT TO 8255y'2 CNTL WD REG 



Obtaining Readings. The Fluke 8375 DOU allows 
readings to be taken in one of two modes. The 
first, a triggered mode, assumes that the external 
triggering has not been inhibited and requires the 
positive edge of a pulse with a minimum width of 
1 microsecond on the trigger input. Setting and 
resetting the port 6 (C) bit 1 produces the 8375 
external trigger. After a reading is triggered the 
8375 busy flag is tested until the not busy state is 
reached. At that time the reading that was 
triggered can be read by the iSBC 80/ 10 A. The 
last statement in this routine jumps to TKDATA 
which reads the data from the DOU and then 
executes the return. 

84 

85 ; 

86 ; »»* SUBROUTINE TO TAKE EXTERNALLY TRIGGERED READING *** 



(37 ; 








88 TRGR: 








39 


MVI 


A, 0000001 OB 


; LD RESET BIT 1 CONTROL WORD 


90 


OUT 


CWR 


; OUTPUT TO 8255#2 CNTL WD REG 


91 


INR 


A 


; MODIFY CONTROL WORD TO SET BIT 1 


92 


OUT 


CWR 


; OUTPUT TO 8255#2 CNTL WD REG 


93 TWT: 








94 


IN 


FLG 


; INPUT THE BUSY FLAG 


95 


ANI 


00100000B 


; TEST PORT C BIT 5 


96 


JNZ 


TWT 


; LOOP UNTIL NOT BUSY 


97 


JMP 


TKDATA 


; GO READ DATA FROM DOU AND RETURN 



The second method for reading the Fluke 8375 is 
to rely on the sample rate set from the front panel 
controls and to wait until a full transition of the 
busy flag is observed. This guarantees that a previ- 
ous reading is not mistakenly interpreted as a new 
reading. 



' SUBROUTINE TO OBTAIN NEXT READING « 



FLG 

OOIOOOOOB 
NXTWT 
TKDATA 



1 INPUT THE BUSY FLAG 

; TEST PORT C BIT 5 

; LOOP UNTIL BUSY WITH NEXT READING 

; INPUT THE BUSY FLAG 

; TEST PORT C BIT 5 

; LOOP UNTIL NOT BUSY 

; GO READ DATA FROM DOU AND RETURN 



Notice that the loops beginning at NXTWT in the 
above program segment and at TWT in the previous 
program segment are identical. This suggests the 
possibility of some obvious code optimization that 
is omitted here for the sake of clarity. 

There is one subroutine remaining to complete full 
utihzation of the Fluke 8375 DOU capabilities. It 
is the subroutine to take data from the 8375 DOU. 
The schematic (Figure 3) shows that port 5 (B) bits 
PB4-PB0 are used to enable the DOU drivers. Data 
from the DOU includes: 

• 5 decades of digits 

• encoded range and overrange 
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The 



function: 

ohms 
modifiers: 
overload 
trigger 

function 



Volts DC, Volts AC, Ohms, Kil- 
Filter, Ext. Ref., Remote 



of this subroutine is to read five 
bytes of data from the 8375 DOU and place them 
in a RAM buffer on the iSBC 80/ 10 A. 



After the operator has entered a command charac- 
ter, the program obtains the address of the sub- 
routine to be executed and proceeds to set up a 
return address on the stack. This technique allows 
a load program counter instruction (PCHL) to be 
used to enter the subroutine and a return instruc- 
tion (RET) to resume execution of the executive. 



' SUBROUTINE TO TAKE DATA FROM 8375 DOU • 



' SIMPLE EXECUTIVE EXERCISE PROGRAM « 



H.RDBUF 
A.OEFH 

B,A 

STB 

DATIN 

M,A 

H 

A,B 



; LD BUFFER POINTER 
; SETUP FIRST STROBE 

SAVE CURRENT STROBE 

STROBE DECADE PAIR 

READ DATA 

PLACE DATA INTO SBC 80/10 RAM 

INCREMENT BUFFER POINTER 

RESTORE STROBE 

RQFATE TO NEXT STROBE POSITION 

LOOP UNTIL BIT STROBE DONE 

DISABLE ALL. STROBES 



128 
129 
130 
131 

132 RET 

133 ; 

This completes the software required to service the 
Fluke 8375 DOU. The following code consists of a 
routine to display the data from the interface on 
the console output device and a short executive 
program to allow exercising of the driver sub- 
routines. 

The display subroutine takes 5 bytes of data from 
the RAM buffer in which the reading has been 
stored and prints them, 2 ASCII characters per 
8-bit byte, on the console. 



1i45 
146 



' SUBROUTINE TO DISPLAY READING BUFFER ON CONSOLE « 



H.RDBUF 
D,5 



LD NEXT BYTE FROM BUFFER 
CALL SBC 80/10 MONITOR SUBROUTINE 
TO DISPLAY ACCUMULATOR CONTENTS 
INCREMENT BUFFER POINTER 
DECRFJ1ENT COUNTER 
LOOP FOR 5 DISPLAY BYTES 



Operator Interface. The short executive program 
provides a tool for the purposes of exercising the 
8375 DOU driver subroutines. The executive begins 
by calling the initiaUzation subroutine and then 
continues on to prompt the operator with a '>' on 
the console. At that point the operator may enter 
one of the following characters, causing the pro- 
gram to execute the specified subroutine: 
SUBR DESCRIPTION 

Enable external trigger 
Disables external trigger 
Enable programmed timeouts 
Disable programmed timeouts 
Next reading 
Trigger and get a reading 
X DISPLAY Display reading buffer 



T 


ETRIG 


I 


DTRIG 


E 


EPOS 


D 


DPOS 


N 


NXTRD 


S 


TRGR 



156 START: 






157 


LXI 


SP, STACK 


153 


CALL 


INIT 


159 EXEC: 






160 


CALL 


CROUT 


161 


MVI 


C,'>' 


162 


CALL 


CO 


163 


CALL 


GETCH 


164 


CALL 


CO 


165 


MOV 


A,C 


166 


LXI 


B.NCMDS 


167 


LXI 


H.CTAB 


168 EXECO: 






169 


CMP 


M 


170 


JZ 


EXECI 


171 


INX 


H 


172 


DCR 


c 


173 


JNZ 


EXECO 


174 


JMP 


EXEC 


175 EXECI: 






176 


LXI 


ri.CADR ; 


177 


DAD 


B ; 


178 


DAD 


B ; 


179 


MOV 


A,M ; 


180 


INX 


H ; 


181 


MOV 


H,M 


182 


MOV 


L,A 


183 


LXI 


D.EXEC 


184 


PUSH 


D 


185 


PCHL 





SETUP STACK POINTER 

INITIALIZE THE SBC 80/10 8255#2 

EXEC ENTRY POINT - PRINT <CR><LF> 
C LOADED WITH PROMPT CHARACTER 
CONSOLE OUTPUT 

GET CMND CHAR, MASK OFF PARITY 
PRINT THE CHARACTER ON THE CONSOLE 
PUT CHARACTER BACK INTO THE ACCUM 
C CONTAINS LOOP AND INDEX COUNT 
HL POINTS TO CMND TABLE 

COMPARE TABLE ENTRY AND CHARACTER 
BRANCH IF FQUAL - CMND RECOGNIZED 
ELSE, INCREMENT TABLE POINTER 
DECREMENT LOOP COUNT 
BRANCH IF NOT AT TABLE END 
ELSE, CMND ILLEGAL - IGNORE IT 

LD ADR OF TABLE OF CMND SUBRS 
ADD WHAT IS LEFT OF LOOP COUNT 
- EACH ENTRY IN CADR IS 2 BYTES 
GET LSP OF ADR OF TABLE ENTRY TO A 
POINT TO NXT BYTE IN TABLE 
GET MSP OF ADR OF TABLE ENTRY TO H 
PUT LSP OF ADR OF TABLE ENTRY TO L 
SETUP RETURN ADR ON THE STACK 

NEXT INSTR COMES FROM CMND SUBR 



The command and address tables as well as the 
reading buffer follow to complete the appHcation 
software. 



COMMAND AND ADDRESS TABLES 



192 CTAB: 
193 

194 NCMDS 

195 ; 

196 CADR: 



NUMBER OF VALID COMMANDS 



198 


DW 


ETRIG 


199 


D<J 


DTRIG 


200 


DW 


EPOS 


201 


DW 


DPOS 


202 


DW 


NXTRD 


203 


DW 


TRGR 


204 


DW 


DISPLAY 


205 ; 






206 ; READING BUFFER AND STACK SPACE 


207 ; 






208 HDBUF: 






209 


DS 


5 ; READING BUFFER 


210 ; 







TRANSFER ADDRESS IS TO START 



SUMMARY/CONCLUSIONS 

This instrumentation control application has been 
presented to demonstrate the simple techniques 
used to apply the iSBC 80/lOA to the task of inter- 
facing instrumentation. A natural extension of this 
example would include the control of the Fluke 
8375 RCU, as well as the control of many addi- 
tional instruments to build a small ATE system. 
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FLUKE 8375 DOU 
(DATA OUTPUT unit: 




Figure 3. Interface Schematic 
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COMMUNICATION 

A diverse range of single board computer applica- 
tions exists in the field of communication. The 
increase in distributed processing generates require- 
ments for self-contained computers to control 
elements of a communication system, increasing 
both the throughput and reliability. 

There are many situations that necessitate monitor- 
ing and controlling a system from a remote site. 
Typical examples are systems that cover large geo- 
graphic areas or systems in dangerous environments 
for human operators. If the object system, which 
provides the actual parallel inputs and outputs to 
the plant, is far from the controlHng system, you 
can lower costs by reducing the number of inter- 
connecting wires via the addition of multiplexers 
to both systems. In the extreme (and often desira- 
ble) case of reducing the interconnects to an 
absolute minimum, all communication between the 
systems takes place on a single serial data link. If 
large distances are involved, this link can be stand- 
ard telephone wires. For moderate distances, the 
link can be a single twisted pair. In either case, the 
equipment used to interface the object system to 
the serial Hnk is called a supervisory control and 
data acquisition (SCADA) terminal. 

The decision to replace a multitude of intercon- 
nects with a SCADA terminal is largely economic. 
Cables and their associated drivers and receivers 
can represent a significant part of the total cost of 
a factory automation project, particularly if an 
electrically noisy environment requires the use of 
shielded cables. Any potential savings in cabling 
must, of course, compensate for the additional cost 
incurred by adding the SCADA terminal to the 
system. 

Communication Application Example 

A SCADA terminal demonstrates an industrial com- 
munication application of the iSBC 80/lOA. The 
Intel® 8251 USART provides the serial communi- 
cation Hnk and the two Intel 8255 Programmable 
Parallel I/O devices provide 48 parallel lines for the 
object system. A block diagram of a SCADA 
terminal is shown in Figure 4. 

The task of the software in this SCADA terminal 
example is two-fold. First, it must continually scan 
its parallel inputs, transmitting the status of those 
lines in a bit serial mode using the USART. And 
second, it receives bit serial data from the USART 
which is to be used to update the parallel outputs. 
Thus, a major portion of the software deals with 
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Figure 4. SCADA Terminal Block Diagram 

the communications protocol on the serial data 
lines. 

Communications Protocol. A communication pro- 
tocol is an agreement between communications 
users that defines the record formats used for data 
transmissions. The protocol selected for this 
SCADA terminal appHcation provides the follow- 
ing features: 

1. A readable character set to simplify the 
human interface. 

2. Error detection by means of a checksum. 

3. Each record specifies the number of data 
bytes in the record and the initial port 
number. 

Despite its value for human interface, the ASCII 
character set has problems representing 8-bit 
binary values, since the high-order bit is not used. 
Therefore, each binary value is treated as two 4-bit 
hexadecimal values. Because hexadecimal numbers 
fall in the range 0-9 and A— F, they can be repre- 
sented as ASCII characters. However, this repre- 
sentation requires twice as many bytes as a pure 
binary format. 

Record Format. The information encoded into the 
ASCII hexadecimal format is grouped to form 
records. Each record has a record mark to flag the 
beginning of the record, a number of ports specifi- 
fication (record length), destination output start 
port number, the data field itself, and a checksum. 

The record format described below is according to 
the fields in the record. 

Record mark field: Byte 

The ASCII code for a colon (:) is used to signal 
the start of a record. 

Number of ports field: Byte 1 

The number of data bytes in the record is repre- 
sented by a single ASCII hexadecimal digit in this 
field. This corresponds to the number of 8-bit 
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ports to which data will be output by the 
SCAD A terminal in a parallel fashion. The maxi- 
mum number of data bytes in a record is 1 5 (F 
in hexadecimal). A record length of zero is a 
special case and can be reserved for control 
information. 

Port address field : Byte 2 

The single ASCII hexadecimal digit in byte 2 
gives the port number of the initial output port. 
The first data byte is output to the port indi- 
cated by the port address; successive bytes are 
output in successive port locations on the iSBC 
80/ lOA or on expansion I/O boards. 

Data field: Bytes 3 to 3+2*(number of ports)-l 

An 8-bit binary value is represented by two 
bytes containing the ASCII characters 0-9 or 
A— F, which represent a hexadecimal value 
between and FF (0 and 255 decimal). The 
high-order digit is in the first byte of each pair. 

Checksum field: Bytes 3+2*(number of ports) to 
3+2*(number of ports)+l 

The checksum field contains the ASCII hexa- 
decimal representation of the two's complement 
of the 8-bit sum of the 8-bit bytes that result 
from converting each pair of ASCII hexadecimal 
digits to one byte of binary, from the number of 
ports field (the number of ports and port ad- 
dress constitute a pair) to and including the last 
byte of the data field. Therefore, the sum of all 
the ASCII pairs in a record after converting to 
binary, from the number of ports field to and 
including the checksum field, is zero. 

Sample Hexadecimal format: 



:3 03AJ 7 8 F F 



- Checksum Field 

- Data Field 

- Starting Port Address 

- Number of Ports 

- Record Mark 



Design Approach Using a State Diagram. Before 
proceeding to examine the software used to imple- 
ment the SCADA terminal, consider how the prob- 
lem might have been approached with TTL logic 
rather than a microcomputer. The design would 
Hkely have been formulated with a state diagram to 
specify the transitions of a sequential state ma- 
chine. The sequential-circuit operations would 
include decoding the serial input records and 



encoding the serial output records. An examination 
of the serial input record state diagram (Figure 5) 
is useful in understanding some of the procedures 
encountered later. 




Figure 5. State Diagram 



Notes: HAC = Hexadecimal ASCII character 

LHAC = Last Hexadecimal ASCII character 
PO = Parallel output 

The receipt of an invalid HAC will cause a return 
to state 0. 

The receipt of a colon at any time will produce a 
transition to state 1 . 



STATE DESCRIPTION 

= record mark state 

1 = number of ports state 

2 = start port number state 

3 = high-order half of data byte state 

4 = low-order half of data byte state 

State is entered at the time of initialization. All 
state transitions occur when the next character is 
received. States 1,2, and 3 are entered with the 
input of a colon (:), the number of ports and start 
port number, respectively. States 3 and 4 will cycle 
as required until all the high and low-order pairs of 
data have been input. The transition from state 4 
to state occurs when the last data byte has been 
received. If the checksum is correct, the parallel 
output latches are loaded with the data field of 
the record. 

There are many references to the states contained 
in this diagram during the discussion of the soft- 
ware procedures. Thus, the state diagram is used as 
a "flowchart" for the software. As in the other 
examples in this appUcation note, a textual descrip- 
tion accompanies each segment of code. Intel's 
high-level programming language, PL/M-80, has 
been used to show the capability to program in a 
natural, algorithmic language which eliminates the 
need to manage register usage or memory alloca- 
tion. 
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SCADA Terminal Program. The program begins 
with a comment, that is followed by the program 
segment label "SCADA". With resident PL/M-80, 
all programs are considered to be labelled blocks, 
or modules. This means that all PL/M programs 
must begin with a LABEL and a DO statement and 
end with an END statement. 



The serial input and serial output state counters are 
set to state 0. Port number is the parallel input 
start port and 3 ports of data are input from the 
parallel ports for serial transmission. 



SRL$IN$STATE = 0; 
SRL$OUT$STATE = 0; 
PRL$IN$STRT$PRT = 0; 
PRL$IN$NMB$PRTS = 3; 



INDUSTRIAL COMMUNICATION APPLICATION 



SCADA TERMINAL 



The Intel 8251 USART must be set up by loading 
it with mode and command instructions. 

The mode instruction format is shown below: 



1 SCADA: 

DO; 

All variables used in the program must be declared 
before they can be referred to by their identifiers. 
This is done by means of a DECLARE statement. 
In addition to the declaration of variables, macros 
are declared using the reserved word LITERALLY. 
These macros are expanded at compile time by 
textual substitution. 



DECLARE 

SRL$IN$STATE BYTE, 
SRL$IN$PRT BYTE, 
SRL$IN$CNT BYTE, 
PRL$IN$STATE BYTE, 
PRL$IN$STRT$PRT BYTE, 
PRL$IN$NHB$PRTS BYTE, 
SRL$IN$PRL$0UT$BFR(3) BYTE, 

PRL$OUT$PRT$0 LITERALLY '0E5H', 
PRL$0UT$PRT$1 LITERALLY 'OEAH', 
PRL$0UT$PRT$2 LITERALLY 'GEBH', 

SRL$0UT$STATE BYTE, 
SRL$0UT$PRT BYTE, 
SRL$0UT$CNT BYTE, 
PRL$0UT$STATE BYTE, 
PRL$OUT$STRT$PRT BYTE, 
PRL$OUT$NMB$PRTS BYTE, 
SRL$0UT$PRL$IN$BFR(4) BYTE, 

PRL$IN$PRT$0 LITERALLY 'OEUH', 
PRL$IN$PRT$1 LITERALLY 'OEeH', 
PRL$IN$PRT$2 LITERALLY '0E.9H' , 

USART$CMD LITERALLY 'OEDH', 
USART$IN LITERALLY 'OECH', 
USART$OUT LITERALLY 'GECH', 
USART$STATUS LITERALLY 'OEDH' , 
USART$MODE$INSTR LITERALLY 'OCFH', 
USART$CMD$INSTR LITERALLY •025H' , 

TXRDY LITERALLY 'OOIH', 
RXRDY LITERALLY '002H', 

PPI$CWR$1 LITERALLY 'OETH', 

PPI$CWR$2 LITERALLY 'OEBH', 

PPI$CWD$1 LITERALLY '080H', 

PPI$CWD$2 LITERALLY 'OgBH', 

TRUE LITERALLY 'OFFH', 
FALSE LITERALLY ■QOOH', 

FOREVER LITERALLY 'k^HILE TRUE', 



NEXT$BYTE BYTE, 
CHECKSUM BYTE; 



8251 and 8255 Initialization. The INIT procedure 
sets up the 8251 and 8255's and initializes several 
variables. Interrupts are disabled to insure that no 
interrupts are serviced during the execution of the 
INIT procedure. 



INIT: PROCEDURE; 
DISABLE; 



^ 1 ' 

Dy I De D5 I D4 



Di I D0 





BAUD RATE FACTOR 


-SYNMODE 

1 =► ASYN XI 

1 ^ASYNXie 
1 1 » ASYN X64 





CHARACTER LENGTH 



=»5BITS 

1 -6 BITS 
10 =»7BITS 

1 1 -»8BITS 



PARITY CONTROL 



XO ^ NO PARITY 

1 'ODD PARITY 

1 1 -EVEN PARITY 




NO- ASYN (Di Do ^0 0) 



FRAMING CONTROL 



=► NOT VALID 

1 =» 1 STOP BIT 

1 =» 1"/2 STOP BITS 
1 1 =» 2 STOP BITS 



YES 

(Di Do = 0) 



SYN CONTROL 



XO INTERNAL SYN 

X 1 EXTERNAL SYN 

OX DOUBLE SYN CHAR 

1 X SINGLE SYN CHAR 



The 8251 characteristics required by this SCADA 
terminal application include 9600 baud transmis- 
sion and 8-bit characters. The parallel inputs of the 
8255's are periodically scanned. The scanning 
frequency is determined by the baud rate and 
number of ports of data being transmitted. For 
example, the transmission of 3 ports of data 
requires 1 1 characters. At a baud rate of 9600 the 
approximate scan rate is 100 Hz. 

The following 8251 mode instruction is used: 



Baud Rate Factor = 10 
Character Length = 11 
Parity Control = GO 
Framing Control = 11 



1100 1110 Binary = CEH 
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After the mode instruction is sent to the 8251, a 
command instruction is required to complete the 
8251 initialization. 

The command instruction format is shown below: 



D7 De D5 D4 D3 D2 Dy Do 



EH IR RTS ER SBRK RxE DTR TxEN 



TRANSMIT ENABLE 
1 = ENABLE 
= DISABLE 



DATA TERMINAL 

READY 

"HIGH" WILL FORCE 
DTR OUTPUT TO ZERO 



RECEIVE ENABLE 
1 = ENABLE RxRDY 
0= DISABLE RxRDY 



SEND BREAK 

CHARACTER 

1= FORCES TxD "LOW" 
0= NORMAL OPERATION 



ERROR RESET 

1 = RESET ALL ERROR 
FLAGS (PE. OE, FE) 



REQUEST TO SEND 
"HIGH" WILL FORCE 
RTS OUTPUT TO ZERO 



INTERNAL RESET 

"HIGH" RETURNS 8251 
TO MODE INSTRUCTION 
FORMAT 



ENTER HUNT MODE 

1 = ENABLE SEARCH FOR 
SYN CHARACTERS 



Initialization of the 8255's is then done to set up 
the following configurations: 

8255 #1 

Port 1 (A) Mode Output 
Port 2 (B) Mode Output 
Port 3 (C) Mode Output 

8255 #2 

Port 4 (A) Mode Input 
Port 5 (B) Mode Input 
Port 6(C) ModeO Input 

The following command instruction is used for the 

8255 #1: 



D5 I D4 I D3 I 0-2 I Di I Dp I 



Port C Bits PC3-PC0 Output = 



Port B Output = 



Port 8 Mode = 



Port C Bits PC7-PC4 Output = 



Port A Output = 



Port A Mode = 00 



Opcode Mode Set = 1 



Mode Control Word =1000 0000 Binary = 80H 



The following command instruction is used for the 

8255 #2: 



The command instruction enables the transmit and 
receive functions of the 8251. 

The following command instruction is used: 



"C 



Transmit Enable = 1 
Data Terminal Ready = 
Receive Enable = 1 
Send Break Character = 
Error Reset = 
Request to Send = 1 
Internal Reset = 
Enter Hunt Mode = 



Instruction = 0010 0101 Binary = 25H 



I D? I 06 



P5 I D4 I P3 I P2 I Dl I Dp I 



Port C Bits PC3-PC0 Input = 1 



Port B Input = 1 



Port B Mode = 



Port C Bits PC7-PC4 Input = 1 



Port A Input = 1 



Port A Mode = 00 



Opcode Mode Set = 1 



Mode Control Word = 1001 1011 Binary = 9BH 



The 8255 initiaUzation commands are given in a 
similar manner to the 8251 commands, 



11 2 0UTPUT(PPI$CWR$1) = PPI$CWD$1; 

12 2 0UTPUT(PPI$CWR$2) = PPI$CWD$2; 



Output instructions send the initialization com- 
mands to the 8251. Note that previously declared 
macros are used to literally replace the mnemonics 
in the following lines of code. 



The INIT procedure concludes by enabling inter- 
rupts. 



OUTPUT(USART$CMD) = USARr$MODE$INSTR; 
OUTPUT(USART$CMD) = USART$CMD$INSTR ; 



13 2 ENABLE; 

14 2 END INIT; 
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Conversion Procedures. Two conversion procedures 
are required in the program. The first procedure 
produces a hexadecimal ASCII character from a 
4-bit binary value. A typed procedure has been 
used which returns a value of the type byte. It is 
called by using its name in an expression. 



15 1 CHAfi$CONV: PROCEDURE (CHAR) BYTE; 

16 2 DECLARE CHAR BYTE; 

17 2 CHAR = CHAR + '0'; 

18 2 IF CHAR > '9' THEN 

19 2 CHAR = CHAR + 7; 

20 2 RETURN CHAfi; 

21 2 END CHAR$CONV; 

The second procedure produces a 4-bit binary 
value from a hexadecimal ASCII character. Because 
this procedure is used only when a hexadecimal 
ASCII character is expected, an illegal character 
(i.e., not a 0-9 or A-F) causes the serial input 
state counter to indicate state 0. This procedure is 
also typed. The NMB$CONV procedure emphatic- 
ally illustrates the point that PL/M-80 performs 
unsigned arithmetic. Note that when the ASCII 
value for a zero is subtracted from the digit, 
NUM = NUM - '0'; a positive number is always 
produced, even if the value of NUM is less than '0'. 



22 


1 


NMB$CONV: PROCEDURE (NMB) BYTE; 


23 


2 


DECLARE NMB BYTE; 


24 
25 
26 
27 
28 

29 
30 
31 


2 

2 
2 
3 
3 

3 
3 
2 


NMB = NMB - '0'; 
IF NMB > 9 THEN 
DO; 

IF (NMB > 16) AND (NMB < 23) THEN 

NMB = NMB - 7; 
ELSE 

SRL$IN$STATE = 0; 
END; 
RETURN NMB; 


32 


2 


END NMB$C0NV; 



Parallel Input Procedure. A parallel input proce- 
dure is used to input data bytes from the 8255's. 
The data bytes are then transmitted by the bit 
serial output device. This procedure also computes 
the checksum for the serial output record. The 
checksum, TEMP2, is initialized to contain the 
parallel input number of ports and the start port, 
shifted to fit within a single byte. Each cycle of the 
iterative DO block adds the next data byte to the 
checksum and places the input data into the 
SRL$OUT$PRL$IN$BFR array until the loop is 
complete. The checksum is then computed as the 
two's complement of the accumulated sum and 
also stored in the serial input parallel output 
buffer. 



33 


1 


PARALLEL$IN: PRXEDURE; 


34 


2 


DECLARE (TEMP1,TEMP2) BYTE; 


35 


2 


TEMP2 : PRL$IN$NMB$PRTS * 16 + PRL$IN$STRT$PRT; 


36 


2 


DO PRL$IN$STATE = PRL$IN$STRT$PRT TO 

PRL$IN$STfiT$PRT + PRL$IN$NMB$PRTS 


37 


3 


DO CASE PRL$IN$STATE; 


3rt 


4 


/» PRL IN PRT •/ 

TEMPI = INPUT(PHL$IN$PRT$0); 


39 


4 


/» PRL IN PRT 1 »/ 

TEMPI z INPUT(PfiL$IN$PRT$1); 


40 


4 


/* PRL IN PHT 2 ♦/ 

TEMPI = INPUT(PRL$IN$PRT$2); 


41 


4 


END; 


42 
43 


3 
3 


SRL$OUT$PRL$IN$BFR(PRL$IN$STATE) = TEMPI; 
TEMP2 s TEMP2 + TEMPI; 


44 


3 


END; 



SRL$OUT$PRL$IN$BFfi( PRL$IN$STRT$PRr -. 
END PARALLEL$IN; 



PRL$IN$NI^$PRTS) 



Parallel Output Procedure. When a complete serial 
input record has been received and the checksum is 
correct, the transition from state 4 to state is 
accompanied by the parallel output of the data 
from the data field of the serial input record. The 
parallel output starting port and the number of 
ports of data is contained in the input record and 
is thus used in directing the parallel output opera- 
tion. An iterative DO block increments the 
PRL$OUT$STATE index variable through the 
required ports and a DO CASE block selectively 
executes one of the OUTPUT statements for each 
cycle of the loop. 



47 


1 


PAfiALLEL$OUT: PROCEDURE; 


4d 


2 


DECLARE TEMP BYTE; 


49 


2 


DO PRL$OUT$STATE = PRL$OUT$STRT$PRT TO 

PriL$OUT$STRT$PRT + PRL$OU' 


50 


3 


TEMP = SRL$IN$PRL$OUT$BFR{PRL$OUT$STATE); 


51 


3 


DO CASE PRL$OUT$STATE; 


52 


4 


/» PRL OUT PRT »/ 
OUrPUT(PRL$OUT$PRT$0) = TEMP; 


53 


4 


/• PRL OUT PRT 1 »/ 
OUTPUT(PfiL$OUT$PRT$l) z TEMP; 


54 


4 


/» PRL OUT PRT 2 •/ 
0UTPUT(PRL$0UT$PRT$2) = TEMP; 


55 
56 


4 
3 


END; 
END; 


57 


2 


END PARALLEL$OUT; 



Serial Input and Output Procedures. The next two 
procedures contain the software implementations 
of the state diagram described previously. The 
processing during each state of the first procedure, 
the serial character input procedure, is described 
in the following text. 

The procedure begins by reading a character from 
the 8251 and then converts the character into a 
4-bit binary value using the number conversion 
procedure. The DO CASE block is the mechanism 
by which a program segment is selected to examine 
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the input character, provide the required outputs, 
and to specify the transition to the next state. 



58 


1 


SERIAL$CHAR$IN: PfiXEOaRE; 


59 


2 


DECLARE (CHAR, TEMP) BYTE; 


60 
61 


2 
2 


CHAR = INPUT(USART$IN) AND 07FH; 
TEMP = NMB$CONV{CHAfi); 


62 


2 


DO CASE SRL$IN$STATE; 



State is entered through the initiahzation proc- 
ess, at the completion of the processing of a serial 
input record, or when an invalid character has been 
received. The serial input state will remain until a 
colon (:) is received, at which time a transition to 
state 1 is specified. 







/» SRL IN STATE = RECORD MARK 


63 


3 


DO; 


64 


it 


IF CHAR = • : • THEN 


65 


i| 


SRL$IN$STATE =1; 


66 


It 


END; 



The parallel output number of ports is obtained, 
the counter initiaHzed, and a transition to state 2 is 
specified from state 1 . 







/* SRL IN STATE 1 = NMB PRTS »/ 


67 




DO; 


68 




PRL$OUT$NMB$PRTS = TEMP; 


69 




SRL$IN$CNT = TEMP; 


70 




SRL$IN$STATE = 2; 


71 




END; 



In state 2 the parallel output starting port number 
is obtained, the serial input port is initiaHzed, the 
checksum is set to contain the parallel output 
number of ports and starting port, and a transition 
to state 3 is specified. 



73 
74 
75 
76 
77 



/• SRL IN STATE 2 = STRT PRT */ 
DO; 

PRL$OUT$STRT$PRT = TEMP; 

SRL$IN$PRT = TEMP; 

CHECKSUM = PRL$0UT$NMB$PRTS»16 + PRL$OUT$STRT$PRT; 

SRL$IH$STATE = 3; 



In state 3 the high-order half of a data byte is 
obtained and shifted into the proper position of 
the NEXT$BYTE variable. A transition is specified 
to state 4. 



78 
79 
80 
81 



/• SRL IN STATE 3 = HI ORDER HALF DATA BYTE »/ 



NEXT$BnE = TEMP* 16; 
SRL$IN$STATE = U; 



State 4 is the final state and requires more process- 
ing than the others. First, a whole byte of data is 
assembled by adding the low and high-order data 
halves, and then testing to determine if the check- 
sum has been received. If so, and the checksum is 
correct, the parallel output procedure is executed. 
Once the entire serial input record has been re- 
ceived, a transition is specified to state whether 
the checksum is correct or not. However, if the 



serial input count has not been exhausted, the 
assembled byte is placed into the serial input 
parallel output buffer and a transition back to state 
3 is specified. 



/« SRL IN STATE 4 = LO ORDER HALF DATA BYTE »/ 



83 


4 


NEXT$BYTE = NEXT$BYTE + TEMP; 


84 


4 


CHECKSUM = CHECKSUM + NEXT$BYTE; 


85 


4 


IF SRL$IN$CNT = THEN 


86 


4 


DO; 


87 


5 


IF CHECKSUM = THEN 


88 


5 


CALL PARALLEL$OUT; 


89 


5 


SRL$IN$STATE = 0; 


90 


5 


END; 
ELSE 


91 


4 


DO; 


92 


5 


SRL$IN$PRL$OUT$BFR(SRL$IN$PRT) = NEXT$BYTE; 


93 


5 


SRL$IN$PRT = SRL$IN$PRT + 1; 


94 


5 


SRL$IN$CNT = SRL$IN$CNT - 1; 


95 


5 


SRL$IN$STATE = 3; 


96 


5 


END; 


97 


4 


END; 


98 


3 


END; /» END OF CASES »/ 


99 


2 


END SERIAL$CHAR$IN; 



The serial character output procedure is similar to 
the serial character input procedure. During state 
the parallel inputs of the 825 5 's are stored in the 
serial output parallel input buffer for transmission. 



100 


1 


SERIAL$CHAR$OUT: PROCEDURE; 


101 


2 


DECLARE (CHAR, TEMP) BYTE; 


102 


2 


CHAR = 0; 


103 


2 


DO CASE SRL$OUT$STATE; 


104 
105 
106 
107 
lOd 


3 
4 
4 
4 
4 


/» SRL OUT STATE = RECORD MARK «/ 
DO; 

CHAR = ':•; 

CALL PARALLEL$IN; 

SRL$OUT$STATE = 1; 
END; 


109 
110 
111 
112 
113 


3 
4 
4 
4 
4 


/» SRL our STATE 1 = NMB PRTS */ 
DO; 

TEMP = PRL$IN$NMB$PRTS; 

SRL$OUT$CNT = TEMP; 

SRL$OUT$STATE = 2; 
END; 


114 
115 
116 
117 


3 
4 
4 
4 


/• SRL OUT STATE 2 = STRT PRT •/ 
DO; 

TEMP = PRL$IN$STRT$PRT; 

SRL$OUT$PRT = TEMP; 

SRL$OUT$STATE = 3; 



127 
128 
129 
130 
131 
132 

133 

134 
135 
136 

137 



END; 

/• SRL OUT STATE 3 = HI ORDER HALF DATA BYTE «/ 
DO; 

TEMP = SHR(SRL$0UT$PRL$IN$BFR(SRL$0UT$PRT),4); 

SRL$OUT$STATE = 4; 
END; 

/» SRL OUT STATE 4 = LO ORDER HALF DATA BYTE »/ 
DO; 

TEMP = SRL$OUT$PRL$IN$BFR(SRL$OUT$PRT) AND OFH; 
IF SRL$OUT$CNT = THEN 

SRL$OUT$STATE =0; 
ELSE 
DO; 

SRL$OUT$CNT = SRL$OUT$CNT - 1; 

SRL$OUT$PRT = SRL$OUT$PRT + 1; 

SRL$OUT$STATE = 3; 
END; 



END; /» END OF CASES »/ 

IF CHAR <> • : • THEN 

CHAR = CHAR$CONV(TEMP); 
■0UTPUT(USART$0UT) = CHAR; 

END SERIAL$CHAR$OUT; 



Interrupt Service Routine. The software in this 
SCADA terminal application example is interrupt 
driven. Interrupts, which occur when the trans- 
mitter of the 825 1 is ready for another character 
or when the receiver has obtained a serial charac- 
ter, direct the execution of either the serial input 



1-20 



or output character procedures. The following 
procedure is entered when an interrupt occurs. 



13(3 


1 


USART$INTf:RRUPT: PPOCEDURf. INTERRUPT 7; 


139 


2 


DECLARE STATUS BYTE; 


mo 


2 


STATUS = INPUT(USAfiT$STATUS); 


1H1 

11*2 


2 

2 


IF (STATUS AND TXRDY) = TXRDY THEN 
CALL SERIAL$CHAR$OUT; 


l'J3 
144 


2 
2 


IF (STATUS AND RXRDY) = HXRDY THEN 
CALL SERIAL$CHAH$IN; 


145 


2 


END USAfiT$INTERRUPT; 



Main Program. The function of the main program 
is rather simple. It calls the initialization routine 
and then loops "FOREVER." Notice that the 
other software is executed only when an interrupt 
occurs. Rather than loop idly while waiting for an 
interrupt, the "main program" could take advan- 
tage of excess CPU time by processing some other 
task. 



CALL INIT; 
DO FOREVER; 



SUMMARY/CONCLUSIONS 

Further consideration should be given to error 
checking in the implementation of a SCAD A termi- 
nal. A checksum has been used in this example 
which provides some error detection but no 
correction. 

The industrial communication example in this 
appUcation note has shown a SCADA terminal. 
Besides providing a convenient forum in which to 
explore the use of PL/M in an interrupt-driven 
environment, this apphcation provides a reaUstic 
and almost fully-developed tool for the replace- 
ment of a multitude of parallel lines. Two such 
systems can be connected through the serial lines 
to provide a parallel to parallel transmission 
scheme as shown in Figure 6. 



PARALLEL I/O 



PARALLEL I/O 




SCADA TERMINAL 



SCADA TERMINAL 



Figure 6. Two SCADA Terminals 
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SERIAL OUTPUT >- 
SERIAL INPUT ^ 




-(( OUT X 




Figure 7. SCADA Terminal Schematic 
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PROCESS CONTROL 

Many single board computers have already been 
applied in the field of process control. Some of the 
common denominators observed in these applica- 
tions include the use of A/D and D/A peripheral 
boards, process monitoring functions such as 
servicing display panels for operator interaction, 
and alarm indicators. 

Temperature Monitoring Application Example 

A temperature monitoring system has been devel- 
oped for the purposes of a process control applica- 
tion example. The single open loop system utilizes 
an A/D converter, a multiplexed display, switches 
for operator control, and two alarms. A block dia- 
gram of the operator's panel is shown in Figure 8 
and a schematic in Figure 9. 





iSBC 80/10A 


TEMPERATURE MONITORING 
OPERATOR'S PANEL 




PORT 5(B) 
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Figure 8. Operator's Panel Block Diagram 

Operator's Panel. The operator's panel in this 
temperature monitoring system contains four 
7-segment displays to show the temperature, two 
light emitting diodes (LEDs) that indicate alarm- 
low and alarm-high conditions, and six switches. 
The function of the switches is as follows: 

Set Limit — controls whether the current 
temperature reading is to be displayed (off) or 
if upper/lower hmits are to be set (on). 

Set Hi Lo - when set limit is "on", this switch 
controls whether the low (off) or high (on) 
limit is to be displayed. 

Digit Selects - these two switches control the 
selection of the digit of the limit which is to 
be modified. The four binary positions 00, 
01, 10 and 1 1 correspond to the four 7- 
segment digits. 



Leave It - controls whether the digit selected 
is to be incremented (ofO or maintained at its 
current value (on). When this switch is "off" 
the digit selected is incremented every 5 1 2 ms 
until the operator turns the switch "on". 

Enable Alarm - when set limit is "off" and the 
current temperature is displayed, this switch 
controls whether the action of the alarm indi- 
cators is to be enabled (on) or disabled (ofO- 

The simple means used to set upper and lower 
temperature limits is similar to setting the time on 
a digital wrist watch. 

The purpose of the software is to initialize the 
system and then to enter an endless loop which 
accumulates 16 readings, updates the displayed 
reading or handles limit setting, updates the display 
latches, waits 4 ms, and obtains an A/D reading. 

Temperature Monitoring Program. This apphcation 
example has been coded in Intel's resident PL/M- 
80 language. 



PROCESS CONTROL APPLICATION 
OPEN LOOP 
TEMPERATURE MONITOR 
*/ 
TEMPER ATUfiE$MONITOR: 



The declaration statement includes some dimen- 
sioned variables with INITIAL attributes. They 
provide data strobe positions, a table of bit pat- 
terns to convert BCD data to 7-segment data, and 
a table of the powers of 10 for binary to BCD 
conversions. 



DECLARE 

READING ADDRESS, 

DIGITS('t) BYTE INITIAL (80H,40H,20H, 10H) , 

BCDT07SEG(n) BYTE MITIAL (^FH,C6H,SBH,4FH,66H, 

6DH,7CH,07H,7FH,67H,0), 
TENS(J4) ADDRESS INITIAL (1000,100,10,1), 
DIGIT$DATA(4) BYTE, 
NXT$DIGIT BYTE, 
UPDATE$COUNT BYTE, 
SET$COUNT BYTE, 
LIMIT(2) ADDRESS, 
ACCUM$RDNG ADDRESS, 

C»^R LITERALLY 'OEBH', 
SLOT LITERALLY 'OEAH', 
SEGS LITERALLY '0E3H', 
Si^TS LITERALLY 'OEgH', 
SErUP$PORTS LITERALLY '082H', 

SET$LIMIT LITERALLY 'OOIH', 
SET$HI$LO IJTERALLY '002H' , 
LEAVE$IT LITERALLY 'OlOH', 
DIGir$SLCT LITERALLY 'OOCH', 
ENABLE$ ALARM LITERALLY •020H', 
SET$ALARM$LO LITERALLY 'OOIH', 
SET$ALARM$HI LITERALLY '003H', 
RESEr$ALAP11$L0 LITERALLY 'OOOH', 
RESET$ALARM$HI LITERALLY '002H', 
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The analog to digital conversion procedure has 
been coded in assembly language and is not in- 
cluded in this application note. It is declared as an 
external typed procedure with no arguments and 
returns a value of the type address. The value 
returned is the current temperature. The ATOD 
procedure is linked later in a step to produce an 
absolute load module of the entire program. 



output to the 8255 port in the same statement. 
The procedure concludes by advancing the 
NXT$DIGIT pointer. 



DISPLAY$UPDATE: PROCEDURE; 

OUTPUT (SEGS) = 0; 

OUTPUT(SLCT) = (DIGITS(NXT$DIGIT) OR (INPUT(SLCT) AND 03H)); 
OUTPUT(SEGS) = BCDT07SEG{DIGIT$DATA(fIXT$DIGIT)); 
NXT$DIGIT = (NXT$DIGIT+1) AND 03H; 

END DISPLA!f$UPDATE; 



3 1 ATOD: PHOCEDURE ADDRESS EXTERNAL; 

4 2 END ATOD; 

Bit set/reset functions of the 8255 have been used 
to control the alarm-low and high output bits. Use 
of this function allows individual bits to be con- 
trolled without affecting others of port C which 
are concurrently selecting the digit to be multi- 
plexed on the display. 

5 1 RESET$ALARMS: PROCEDURE; 

6 2 OUTPUT(CWR) = RESET$ALARM$LO; 

7 2 OUTPUT(CWR) = RESET$ALARH$HI ; 

6 2 END RESET$ALARMS; 

The following procedure is used to initialize the 
8255 and several program variables. 



9 


1 


INIT: PROCEDURE; 


10 


2 


OUTPUT(CWR) = SETUP$PORTS; 


11 


2 


CALL RESET$ALARMS; 


12 


2 


NXT$DIGIT = 0; 


1.^ 


2 


UPDATE$COUNT = 0; 


^^ 


2 


SET$COUNT = 7; 


15 


2 


READING = 0; 


lb 


2 


ACCUM$RDNG = 0; 


17 


2 


LIMIT(O) = 0000; 


Id 


2 


LIMIT(I) = 9999; 


19 


2 


END INIT; 



A multiplexed display is controlled by the soft- 
ware. Two ports of an 8255 are required for this 
function shown in Figure 9. The first output port 
holds the data which drives the four 7-segment dis- 
plays in parallel. The second output port contains 
four strobes, each going to a separate common 
cathode of one of the 7-segment displays. 

The update display procedure begins by blanking 
7-segment data in the output port. This step avoids 
shadows that would be produced if the data for 
the next digit position were loaded prior to up- 
dating the strobe. The strobe is then advanced, 
retaining the alarm bits that occupy other bits of 
the same output port. Note that an output con- 
figured 8255 port can be read with an 8080 A 
INPUT instruction to determine the currently 
latched output data. The BCD data is obtained 
from the next digit position of the DIGIT$DATA 
array and used as a subscript into a table of 
BCDT07SEG data. The 7-segment data is also 



Binary to BCD Conversion. Binary data from the 
A/D converter must be converted to BCD before it 
can be used by the DISPLAY$UPDATE procedure 
to show the current temperature reading. The 
BINTOBCD procedure performs this conversion 
operation. 



26 


1 


BINTOBCD: PROCEDURE; 


27 


2 


DECLARE (BCD, I) BYTE; 


2d 


2 


DO I = TO 3; 


29 
30 


3 

3 


BCD = 0; 

DO WHILE READING >= TENS(I); 


31 
32 




READING = HEADING - TENS(I) 
BCD = BCD + 1 ; 


33 


n 


END; 


3'4 


3 


DIGIT$DATA(I) = BCD; 


35 


3 


END; 


36 


2 


END BINTOBCD; 



BCD to Binary Conversion. The reverse conversion 
process is also needed. That is, BCD data must be 
converted to binary. This procedure is used to take 
limits, which are set by manipulating BCD digits, 
and convert them to binary data for use in testing 
against current temperature readings. Based vari- 
ables have been used in this procedure to allow 
access to the actual variables used as arguments in 
the calling program. 

37 1 BCDTOBIN: PROCEDURE (BCD$ARRAY$ADR,BIN$DATA$ADR) ; 

3d 2 DECLARE 

( BCD$ARRAY$ADR , BIN$DATA$ADR) ADDRESS , 
(BCD$ARRAY BASED BCD$ARRAY$ADR) (n) BYTE, 
(BIN$DATA BASED BIN$DATA$ADR) ADDRESS, 
I BYTE; 

39 2 BIN$DATA = 0; 
W 2 DO I = TO 3; 

/* BIN$DATA = BIN$DATA»10 + BCD$ARRAY(I) •/ 

41 3 BIN$DATA = SHL(BIN$DATA, 1) + SHL(BIN$DATA,3) + BCD$ARRAY(I) ; 

42 3 END; 



Updating the Display. The UPDATE procedure is 
entered each time 16 readings have been taken 
from the A/D converter. The UPDATE $COUNT is 
reset and the operator switches are input to control 
the execution path through the procedure. The 
accumulated reading, which is the total of 1 6 A/D 
readings, is divided by 16 to obtain an average 
reading. Then the accumulated reading is zeroed. 
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44 1 UPDATE: PROCEDURE; 

45 2 DECLARE (SWT$FLG,HI$LO, DIGIT) BYTE; 



UPDATE$COUNT =15; 
SWT$FLG = INPUT(SWTS); 
READING = SHR(ACCUM$RDNG,4); 
ACCUM$HDNG = 0; 



The reading is compared with both the upper and 
lower hmits if the alarms have been enabled. The 
results of the tests are used to set and reset the 
corresponding alarm output bits. 



Setting Limits. If the set limit switch is ON, the 
limits are to be dealt with instead of testing and 
displaying the current temperature reading. The 
alarms are reset during limit setting. The specified 
hmit is converted to BCD and then the Leave-It 
switch is tested to see if the digit selected is to be 
incremented or held constant. 

50 2 IF (SWT$FLG AND SET$LIMIT) = SET$LIMIT THEN 



51 


2 


DO; 


52 




CALL fiESET$ALARMS; 


53 




HI$LO = SHR((SWT$FLG.AND SE:T$HI$L0) , 1 ) ; 


54 




READING = LIMIT(HI$LO); 


55 




CALL BINTOBCD; 


56 




IF (SWT$FLG AND LEAVE$IT) <> LEAVE$IT THEN 



Another counter is used to control digit incre- 
menting. Its purpose is to control the rate at which 
the selected digit is to be incremented. The major 
loop in the program has a 4-minisecond delay. 
Thus, 16 A/D conversions require a period of 
64 ms which provides an update frequency of 16 
readings per second. This is too fast to accurately 
select a desired digit which is being incremented. 
SET$COUNT insures eight update periods (512 
ms) between each increment. After the digit has 
been incremented, the BCD limit value is con- 
verted back to binary to set the respective hmit. 
This concludes the action taken when setting 
hmits. 



IF SET$COUNT = THEN 
DO; 

SET$COUNT = 7; 

DIGIT = SHfi((SWT$FLG AND DIGIT$SLCT) ,2) ; 

IF DIGIT$DATA(DIGIT) = 9 THEN 
DIGIT$DATA( DIGIT) = 0; 

DIGIT$DATA( DIGIT) = DIGIT$DATA( DIGIT) ■ 
CALL BCDTOBIN( .DIGIT$DATA, .LIMrr(HI$LO)) ; 



SET$COUNT = SET$COUNT - 1 ; 



Testing the Averaged Reading. If the set limit 
switch is OFF, then the averaged reading is to be 
tested and displayed. The averaged reading is con- 
verted to BCD and then a test is performed to 
determine whether the reading is to be compared 
with the upper and lower hmits. 



73 


3 


DO; 


74 


4 


IF HEADING < LIMIT{0) THEN 


75 


4 


OUTFUT(CWR) = SET$ALARM$LO; 

ELSE 


76 


4 


OUTPUT(CWR) = RESET$ALARM$LOi 


77 


4 


IF HEADING > LIMIKD THEN 


76 


4 


OUTPUT(CWR) = SET$ALARM$HI; 
ELSE 


79 


4 


OUTPUT(CWR) = RESET$ALARM$HI; 


do 


4 


END; 



If the alarms are not enabled, both the alarms are 
reset to the "off" condition. 



81 
82 

83' 



ELSE 

CALL RESET$ ALARMS; 



END; 
END UPDATE; 



Main Program. The main program is shown below. 
Its purpose is to initialize the system and then to 
cycle, continuously executing the code previously 
described. 







MAIN$PROGfiAM: 


84 


1 


CALL INIT; 


85 


1 


DO FOREVER; 


86 


2 


ACCUM$RDNG = ACCUM$RDNG + READING; 


87 
88 

89 


2 
2 

2 


IF UPDATE$COUNT = THEN 

CALL UPDATE; 
ELSE 

UPDATE$COUNT = UPDATE$COUNT - 1 


90 
91 
92 


2 
2 
2 


CALL DISPLAY$UPDATE; 
CALL TIME(40); 
READING = ATOD; 



CALL BINTOBCD; 

IF (SWT$FLG AND ENABLii:$ ALARM) = ENABLE$ALARM THEN 



SUMMARY/CONCLUSIONS 

The goal of this appHcation example is to demon- 
strate some of the common functions required for 
process control systems. Rather than show a small 
portion of a larger, more complex problem, this 
example was chosen because it presents a complete 
solution to a smaller problem. In summary, refresh- 
ing a multiplexed display was shown. Conversion 
procedures for binary to BCD and BCD to binary 
were used. A simple technique, in terms of hard- 
ware requirements, was used to enter lower and 
upper test values. And, limits testing was done, 
providing alarm indicators. 
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^ Vcc 



ALARM LO 



Figure 9. Operator's Panel Schematic 
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I/O DEVICE CONTROLLER 

Peripheral processors have become common ele- 
ments in computer systems of all sizes and capa- 
bilities. The purpose of such a processor is to 
relieve a central processor from the burden of 
handling I/O devices. In effect, it is a form of 
distributed processing. The iSBC 80/lOA can be 
used as a peripheral processor and/or as an I/O 
device controller. In such a capacity it can signifi- 
cantly reduce the amount of hardware required to 
interface peripherals. Because the iSBC 80/lOA 
controls only I/O, it is of little consequence that 
it must do a great deal of detail work that other- 
wise wastes the processing capability of a larger 
central processor. 

Consider the activity of producing a listing on a 
Hne printer. The overhead in maintaining a pro- 
gram in the queue of a central processor which is 
producing data for a line printer can seriously 
impact system throughput. If, however, the pro- 
gram were to send the list to a disk file and then 
command a peripheral processor to take care of the 
printing, a significant improvement in system 
performance may be achieved. Printers represent 
one example of a large number of I/O devices that 
can be controlled by an iSBC 80/lOA. Other 
devices include cassettes, magnetic tape drives, 
paper tape readers and punches, etc. 

Character Printer Controller Application Example 

The control of a Centronics 306 character printer 
is used as an I/O device controller apphcation 
example. This example shows the interrupt capa- 
biUty of mode I 8255 operation. A block diagram 
of the printer controller is shown in Figure 1 and 
a schematic in Figure 1 1 . 



iSBC 80/lOA 
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DATA 
CONTROL 
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Figure 10. Printer Controller Block Diagram 



When the mode 1 or mode 2 configuration is used, 
software is generally required to support interrupts 
used in conjunction with handshaking operations. 
Software routines written for an interrupt driven 
environment tend to be more complex than status 
driven routines. The added complexity is because 
interrupt-driven systems are constructed such that 
other software tasks are run while the I/O transac- 
tion is in progress. A software routine that controls 
a peripheral device is generally referred to as a 
device driver. One method of implementing an 
interrupt-driven device driver is to partition the 
device driver into a "command processor" and an 
"interrupt service routine." The command proces- 
sor is the module that validates and initiates user 
program requests to the device driver. A common 
method of passing information between the various 
software programs is to have the requesting routine 
provide a device control block in memory. The 
device control block used in this apphcation 
example is shown in Table 2. 



Table 2. Printer Software Control Block 




NAME 


POSITION 


DEFINITION 


Status 


ByteO 


A 1-byte field which defines the completion status of an I/O. 

00 = Good completion 

01 = Error — command already in progress. 


Buffer Address 


Byte 1,2 


Pointer to the start of the data to print. 


Character Count 


Byte 3 


Count of the number of characters to print. 


Character 


Byte 4 


The number of characters transferred. 


Transferred Count 






Completion 


Byte 5, 6 


Address of a user supplied routine which will be called after the I/O has been 


Address 




performed. 
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The command processor validates the transaction 
and initiates the operation described by the control 
block. Control is then returned to the requester 
so that other processing may proceed. The inter- 
rupt service routine processes the remainder of the 
transaction. 

Interrupt Service Routine Requirements. The 
interrupt service routine requires the following 
functions: 

1. The state of the machine (registers, status, 
etc.) must be saved so that it may be re- 
stored after the interrupt is processed. 

2. The source of the interrupt must be deter- 
mined. The hardware may support a register 
which indicates the interrupting device, or 
the software may poll the device status 
registers. 

3. Data must be passed to or from the device. 

4. Control must be passed to the requesting 
routine at the completion of the I/O. 

5. The state of the machine must be restored 
before returning to the interrupted program. 

Printer Controller Program. The software for this 
appUcation has been coded using Intel® 8080 
Macro Assembly Language. 



I/O DEVICE CONTROLLER APPLICATION 
INTERRUPT DRIVEN 
CHARACTER PRINTER 



The following program equates are used to allow 
symbolic reference to the 8255 ports. Group #1 
8255 on the iSBC 80/lOA has been used because 
it will support mode 1 operation. 



12 ; 

13 ;»«»»« 

TJ PORTA 

15 PORTB 

16 PORTC 

17 CWR 


PROGRAM EQUATES 




EQU 0E4H 
EQU 0E5H 
EQU 0E6H 
EQU OETri 


8255 PORT A 
8255 PORT B 
8255 PORT C 
8255 CONTROL WORD REGISTER 



An initiaHzation control word sent to the control 
word register of the 8255 will set up the desired 
configuration. 



23 ; 

214 ; 

25 ; 

26 ; 



INITIALIZATION CONTROL WORD 

USED TO CONFIGURE THE 8255 AS FOLLOWS: 

PORT A - OUTPUT MODE 1 

PORT B - INPUT MODE (NOT USED) 

PORT C LOWER - OUTPUT 

EQU 10101010B ; INITIALIZATION CONTROL WORD 



The bit set/reset capabiHty of the 8255 is used to 
control the strobe to the printer and to enable/ 
disable interrupts from the 8255. 



32 ; 


SET/ RESET CONTROL WORDS 


33 ;*»»•» 




34 STBON 


EQU 0000000 IB ; SET STROBE 


35 STBOF 


EQU OQOOOOOOB ; RESET STROBE 


36 ;*«»«« 




37 ; 

38 ;***** 

39 lEN 


8255 ENABLE/DISABLE INTERRUPT CONTROL WORDS 


EQU 00001 101B ; ENABLE INTERRUPTS 


40 IDN 


EQU 00001 lOOB ; DISABLE INTERRUPTS 



Device status, control block, and completion 
equates are shown below. 



42 ; 


DEVICE STATUS EQUATES 


143 ;«•**« 








44 LPBSY 


EQU 


080H 


BUFFER FULL (LINE PRINTER BUSY) 


45 INTRA 


EQU 


08H 


INTERRUPT REQUEST 


46 ;***** 








47 ; 

48 ;»»»** 

49 CBST 


CONTROL BLOCK EQUATES 


EQU 


OGH 


STATUS BYTE 


50 CBUF 


EQU 


01H 


BUFFER ADDRESS 


51 CBCC 


EQU 


03H 


CHARACTER COUNT 


52 CBCT 


EQU 


04H 


CHARACTER TRANSFERED COUNT 


53 CBCMP 

54 ■**»*• 

55 ; 

56 ;»»•»• 

57 STGD 


EQU 


05H 


COMPLETION SERVICE ADDRESS 


COMPLETION STATUS EQUATES 


EQU 


OOH 


GOOD COMPLETION 


58 STE1 


EQU 


01H 


ERROR - COMMAND ALREADY IN PROGRESS 


59 :•»»»» 









There are two origin statements in this program. 
The first origin at 38 hexadecimal is the entry 
point used when an interrupt is generated by the 
8255. A jump instruction to the printer interrupt 
routine is stored at that location. The second 
origin at 3000 hexadecimal is the address where 
the rest of the code will be located. 



63 

64 ; 

65 ; 

66 ; 
67 



RESTART 7 ENTRY POINT 



OO38H 
PINT 



PROGRAM ORIGIN 



An initiaHzation subroutine issues the mode con- 
trol word to the 8255 control word register after 
reset of the device. The printer strobe must then be 
disabled. 



70 ; 

71 ; 

72 ; 

73 ; 

74 ;«»«»# 


INITIALIZATION ROUTINE 


A,H,L REGISTERS MODIFIED 






75 INIT: 






76 


MVI 


A.ICW ; GET MODE CONTROL WORD 


77 


OUT 


CWR ; OUTPUT TO CONTROL WORD REGISTER 


78 


MVI 


A, STBON ; GET SET DATA STROBE CONTROL WORD 


79 


OUT 


CWR ; SET DATA STROBE (LOW TRUE SIGNAL) 


80 


RET 


; RETURN TO CALLER 



The command processor is started by the user 
routine through a subroutine call to PSTRT, with 
the address of the control block in the D and E 
registers. The command processor insures that an 
I/O operation is not already in progress, starts the 
I/O, enables interrupts, and returns to the caller so 
that other processing may proceed. 
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The flowchart and Hsting for the command proces- 
sor are shown below. 




'^COMMANDX. Y£s 

^progre: 



SET 

COMMAND 
IN PROGRESS 



< POST TO \ 
USER / 



<call\ 
OUTPUT y 
DATA / 



ENABLE 
PROCESSOR 
INTERRUPTS 



90 
91 

92 i 

93 ; 
9i4 PSTRT: 
95 

96 
97 



COMMAND PROCESSOR 

INPUTS: CONTROL BLOCK ADDRESS IN D AND E REGISTERS 
OUTPUTS: START I/O OR ERROR STATUS IN CONTROL BLOCK 

A,H,L REGISTERS MODIFIED 



GET PRINT IN PROGRESS BLOCK ADDRESS 

SEE IF ZERO (PRINT IN PROGRESS) 

IF BLOCK ADDRESS NOT EQUAL TO ZERO THEN 

PRINT IN PROGRESS 

IF YES - BRANCH TO ERROR 



112 PSTE: 
113 



XCHG 
SHLD 
XCHG 
LXI 
DAD 
MVI 
CALL 



PIPRG 
H.CBCT 



SAVE CONTROL BLOCK ADDRESS 

GET INDEX TO CT 

COMPUTE ADDRESS OF CT 

CLEAR CT 

START I/O 

ENABLE PRXESSOR INTERRUPTS 

RETURN TO CALLER 



ERROR - TRANSACTION ALREADY IN PROGRESS 



Interrupt Processing. When the 8255 generates an 
interrupt, the interrupt request is serviced by the 
8080A CPU. The CPU disables processor interrupts 
and then executes the instruction at location 38 
hexadecimal, which is a jump to the interrupt 
service routine. The interrupt service routine saves 
the processor state and polls the 8255 to determine 
the source of the interrupt. Once the interrupting 
device is identified, the printer output data routine 



is called. After the entire buffer has been printed, 
the interrupt service routine passes control to the 
user-supplied completion routine. Before returning 
from the interrupt, the state of the processor is 
restored. 

There are a number of error conditions which may 
occur, such as an interrupt from a device that does 
not have an active control block, or an interrupt 
when polling establishes that no device requires 
service. Neither of these errors should occur, but if 
they do, the driver should perform in a consistent 
fashion. The recovery routines implemented to 
handle these interrupt error conditions are deter- 
mined by the environment of the particular appli- 
cation. 

The flowchart and Hsting for the printer interrupt 
service routine are shown below. 




117 
118 


***** 


PRINTER 


INTERRUPT SERVICE ROUTINE 


119 




ALL REGISTERS SAVED AND RESTORED 


120 


«•««« 






121 PINT: 






122 


PUSH 


PSW ; SAVE PSW 


123 


PUSH 


B ; SAVE REGISTER PAIR B AND C 


124 


PUSH 


D ; SAVE REGISTER PAIR D AND E 


125 


PUSH 


H ; SAVE REGISTER PAIR H AND L 


126 


*»»»» 
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127 J 


POLL INIERRUPT SOURCE - SEE OF 8255 


165 








128 ,***** 








166 ;«»»•• 








129 


IN 


PORTC 


GET STATUS OF DEVICE 


167 ; 








130 


ANI 


INTRA 


SEE IF INT 


168 ; 


PRINTER OUTPUT DATA ROUTINE 


131 


JZ 


PPOLL 


NO -BRANCH TO POLL OTHER DEVICES IF ANY 


169 ; 








132 


MVI 


A.IDN 


GET 8255 INT DISABLE CONTROL WORD 


170 ; 


CONTROL BLOCK ADDRESS IN D AND E REG 


133 


OUT 


CWR 


DISABLE DEVICE INTERRUPTS 


171 ; 








131^ 


EI 




ENABLE PROCESSOR INTERRUPTS 


172 ;•»•»» 








135 


LHLD 


PIPRG 


GET CONTROL BLOCK ADDRESS 


173 PDATA: 








136 


XRA 


A 


CLEAR A REG 


174 


IN 


PORTC 


GET STATUS OF DEVICE 


137 


CMP 


H 


SEE IF PRINT IN PROGRESS 


175 


ANI 


LPBSY 


SEE IF BUSY (BUFFER FULL) 


138 


JZ 


PIER1 


NO - BRANCH TO ERROR ROUTINE 


176 


JZ 


PD10 


IF BUSY - BRANCH 


139 


XCHG 






177 


LXI 


H.CBCT 


GET INDEX TO CT 


mo 


CALL 


PDATA 


PRINT DATA 


178 


DAD 


D 


COMPUTER ADDRESS OF CT 


141 


»•«•• 








179 


MOV 


A,M 


GET CT 


142 




RESTORE REGISTERS AND RETURN FROM INTERRUPT 


180 


INR 


M 


INC CT 


143 


•«»f« 








181 


DCX 


H 


DEC TO CC 


144 PRTN: 








182 


CMP 


M 


SEE IF EQUAL 


145 


POP 


H 


RESTORE REGISTER PAIR H AND L 


183 


JZ 


PCOMP 


IF EQUAL - DONE GO TELL USER 


146 


POP 


D 


RESTORE REGISTER PAIR D AND E 


184 


LXI 


H.CBUF 


GET INDEX TO BUFFER ADDRESS 


147 


POP 


B 


RESTORE REGISTER PAIR B AND C 


185 


DAD 


D 


COMPUTE ADDRESS OF BUFFER ADDRESS 


148 


POP 


PSW 


RESTORE PSW AND A 


186 


PUSH 


D 


SAVE D AND E REGISTERS 


149 


EI 




ENABLE PROCESSOR INTERRUPTS 


187 


MOV 


E,M 


GET LSB 6F buffer ADDRESS 


150 


RET 




RETURN TO INTERRUPTED PROCESS 


188 


INX 


H 


INC TO NEXT BYTE 


151 


««••» 








189 


MOV 


O.M 


GET BUFFER MSB 


152 




POLL OTHER DEVIC 


:S IF ANY 


190 


MVI 


H.OOH 


CLEAR H REG 


153 






IF NO OTHER DIVICES TO POLL - USER SUPPLIED ERROR 


191 


MOV 


L,A 


GET CT 


154 






RECOVERY 


ROUTINE. 


192 


DAD 


D 


COMPUTER CHARACTER ADDRESS 


155 


«*«•» 








193 


MOV 


A.M 


GET CHARACTER 


156 PPOLL: 








194 


OUT 


PORTA 


OUTPUT CHARACTER TO PRINTER 


157 


JMP 


PRTN 


RETURN 


195 


MVI 


A.STBOF 


RESET DATA STROBE (LOW TRUE SIGNAL) 


158 


»•••» 








196 


OUT 


CWR 




159 




ERROR 


- INTERRUPT 


FROM IDLE DEVICE 


197 


INR 


A 


GENERATE SET CONTROL WORD 


160 






USER SUPPLIED ERROR RECOVERY ROUTINE 


198 


OUT 


CWR 


SET DATA STROBE 


161 


*••«• 








199 


POP 


D 


RESTORE CONTROL BLOCK ADDRESS 



162 PIER1: 

163 

164 



LOOP UNTIL BUSY 



The printer output data routine places a character 
in the output buffer of the 8255. Data in the 
control block is used to direct the transfer of a 
character. A data strobe signal is then generated 
through the use of the port C bit set/reset feature. 

The flowchart and hsting for the printer output 
data routine are shown below. 



If the printer is busy at the time the printer output 
routine is called, a printer busy routine is executed. 
The printer busy routine disables the processor 
interrupts, enables the 8255 interrupts and then 
enables the processor interrupts on its return to 
the caller. 




204 ; 


PRINTER BUSY - 


RETURN 


205 ;•"»• 






206 PDIO: 






207 


DI 




DISABLE INTERRUPTS 


208 


MVI A.IEN 




ENABLE DEVICE INTERRUPTS 


209 


OUT CWR 




SET INTERRUPT ENABLE 


210 


RET 




RETURN TO CALLER 



DISABLE 
PROCESSOR 
INTERRUPTS 
ENABLE 8255 
INTERRUPTS 



When the printer output routine has exhausted the 
data from the buffer, a good status code is posted 
to the user. The command in progress flag is also 
cleared. 



NO 


YES 














GOODCOMP 


GET CHAR 






















STORE 
STATUS 


OUTPUT 
CHARACTER 




GENE 
STRO 


RATE 
JE 









211 ;*•••• 






212 ; 


POST GOOD COMPLETION TO USER 


213 ;•••" 






214 PCOMP: 






215 


MVI 


A.STGD ; GET GOOD STATUS CODE 


216 


CALL 


POST ; POST TO USER 


217 


XRA 


A ; CLEAR A REG 


218 


STA 


PIPfiG+1 ; CLEAR COMMAND IN PROGRESS ADDRESS 


219 


RET 


; RETURN TO CALLER 



The post to user completion routine obtains the 
completion address from the device control block 
and passes control to the user routine. 



222 
223 
224 
225 
226 
227 
22^ 
229 
230 
231 
232 
233 
234 



POST TO USER COMPLETION ROUTINE 



STATUS CODE IN A REG 
CONTROL BLOCK ADDRESS IN D AND E REG 
; PASSES CONTROL TO USER COMPLETION ADDRES 
SPECIFIED IN CONTROL BLOCK 
WITH CONTROL BLOCK ApDRESS IN D AND E RE 



A.H.L.B.C REG MODIFIED 
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235 POST: 










236 


XCHG 








237 


MOV 


M,A. 


; UPDATE STATUS 




238 


XCHG 








239 


LXI 


H.CBCMP 


; GET INDEX TO COMPLETION ADDRESS 




240 


DAD 


D 


; COMPUTE ADDRESS 




241 


MOV 


CM 


; GET LSB OF COMPLETION ADDRESS 




242 


INX 


H 


; INC TO NEXT BYTE 




243 


MOV 


B,M 


; GET MSB OF COMPLETION ADDRESS 




244 


PUSH 


B 


; PUSH ADDRESS ON STACK 


GROUP 


245 


RET 




; PASS CONTROL TO USER ROUTINE 


8255 


246 ;"»»• 










247 ; 


DATA AND TABLES 






248 ;•»»•• 










249 


ORG 


3D00H 






250 PIPfiG: 


DW 





; IN PROGRESS CONTROL BLOCK ADDRESS 




251 






; IF DATA = NO CONTROL BLOCK IN PROGRESS 




252 






; IF DATA <> CONTROL BLOCK IN PROGRESS 




253 ;••"• 










254 ; 


END OF MODE ONE 


EXAMPLE 




255 ]***** 










256 


END 
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SUMMARY/CONCLUSIONS 

The iSBC 80/lOA has the capability to function in 
the capacity of a peripheral processor and/or a 
device controller. This capability is provided in 
part by the interrupt support logic accompanying 
the parallel I/O ports. This appHcation example 
shows how the iSBC 80/lOA requires only an inter- 
connect to the device to be controlled. 
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Figure 11. Printer Controller Schematic 
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CONCLUSION 

The purpose of this application note has been to 
expose the reader to a broad spectrum of potential 
apphcations of the Intel iSBC 80/lOA and System 
80/10 products. Apphcations have been presented 
in the areas of instrumentation, communication, 
process control and I/O device control. The exam- 
ples were Hmited to short problems that could be 
completely described. 

Intel's PL/M-80 and 8080 Macro Assembly Lan- 
guage were both used in the examples. Instead of 
using only assembly language, it was felt that 
PL/M-80 should also be shown. Coding in an 
algorithmic language is generally more natural than 
assembly language and provides these added bene- 
fits: reduced program development time and cost, 
improved product rehabiUty, and easier program 
maintenance. 



While the task of actually configuring the SBC 
80/10 for the applications has not been described 
in this note, detailed instructions are contained in 
the tables of Chapter 4 in thQiSBC 80/10 and iSBC 
80/lOA Single Board Computer Hardware Refer- 
ence Manual. 

The Intel iSBC 80/lOA has been designed to pro- 
vide users with subsystems that have processing 
power, memory storage, parallel and serial pro- 
grammable I/O interfaces. A design goal of the 
iSBC 80/lOA was to minimize the requirements 
for customized interface hardware in user applica- 
tions. This apphcation note has demonstrated the 
achievement of this goal. The net effect is to 
reduce the number of tedious design tasks, thus 
allowing the systems designer to concentrate on 
systems integration and other problems unique 
to his job. 
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APPENDIX A 
iSBC 80/1 OA SCHEMATICS 
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I. INTRODUCTION 

A significant measure of the power and flexibility 
of the Intel OEM Computer Product Line can be 
attributed to the design of the Intel MULTIBUS 
system bus. The bus structure provides a common 
element for communication between a wide 
variety of system modules which include: Single 
Board Computers, memory, digital, and analog 
I/O expansion boards, and peripheral controllers. 

The purpose of this application note is to help you 
develop a working knowledge of the Intel MULTI- 
BUS specification. This knowledge is essential for 
configuring a system containing multiple mod- 
ules. Another purpose is to provide you with the 
information necessary to design a bus interface for 
a slave module. One of the tools that will be used to 
achieve this goal is the complete description of a 
MULTIBUS slave design example. Other portions 
of this application note provide an in depth 
examination of the bus signals, operating charac- 
teristics, and bus interface circuits. 

This application note was originally written in 
1977. Since 1977, the MULTIBUS specification 
has been significantly expanded to cover opera- 
tion with both 8 and 16-bit system modules and 
with an auxiliary power bus. This application 
note now contains information on these new 
MULTIBUS specification features. 

In addition, a detailed MULTIBUS specification 
has also been published which provides the user 
with further information concerning MULTIBUS 
interfacing. The MULTIBUS specification and 
other useful documents are listed in the overleaf of 
this note under Related Intel Publications. 



XL MULTIBUS™ SYSTEM BUS 
DESCRIPTION 

Overview^ 

The Intel MULTIBUS signal lines can be grouped 
in the following categories: 20 address lines, 16 
bidirectional data lines, 8 multilevel interrupt 
lines, and several bus control, timing and power 
supply lines. The address and data lines are 
driven by three-state devices, while the interrupt 
and some other control lines are open-collector 
driven. 

Modules that use the MULTIBUS system bus have 
a master-slave relationship. A bus master module 
can drive the command and address lines: it can 
control the bus. A Single Board Computer is an 
example of a bus master. A bus slave cannot 



control the bus. Memory and I/O expansion 
boards are examples of bus slaves. The MULTI- 
BUS architecture provides for both 8 and 16-bit 
bus masters and slaves. 

Notice that a system may have a number of bus 
masters. Bus arbitration results when more than 
one master requests control of the bus at the same 
time. A bus clock is usually provided by one of the 
bus masters and may be derived independently 
from the processor clock. The bus clock provides a 
timing reference for resolving bus contention 
among multiple requests from bus masters. For 
example, a processor and a DMA (direct memory 
access) module may both request control of the 
bus. This feature allows different speed masters to 
share resources on the same bus. Actual transfers 
via the bus, however, proceed asynchronously 
with respect to the bus clock. Thus, the transfer 
speed is dependent on the transmitting and 
receiving devices only. The bus design prevents 
slow master modules from being handicapped in 
their attempts to gain control of the bus, but does 
not restrict the speed at which faster modules can 
transfer data via the same bus. Once a bus request 
is granted, single or multiple read/ write transfers 
can proceed. The most obvious applications for the 
master-slave capabilities of the bus are multi- 
processor configurations and high-speed direct- 
memory-access (DMA) operations. However, the 
master-slave capabilities of the bus are by no 
means limited to these two applications. 

MULTIBUS™ Signal Descriptions 

This section defines the signal lines that comprise 
the Intel MULTIBUS system bus. These signals 
are contained on either the PI or P2 connector of 
boards compatible with the MULTIBUS specifi- 
cation. The PI signal lines contain the address, 
data, bus control, bus exchange, interrupt and 
power supply lines. The P2 signal lines contain the 
optional auxiliary signal lines. Most signals on 
the bus are active-low. For example, a low level on 
a control signal on the bus indicates active, while a 
low level on an address or data signal on the bus 
represents logic "1" value. 

NOTE 

In this application note, a signal will be 
designated active-low by placing a slash (/) 
after the mnemonic for the signal. 

Appendix A contains a pin assignment list of the 
following signals: 
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MULTIBUS PI Signal Lines - 

Initialization Signal Line 

INIT/ 

Initialization signal; resets the entire system to 
a known internal state. INIT/ may be driven by 
one of the bus masters or by an external source 
such as a front panel reset switch. 

Address and Inhibit Lines 

ADRO/ - ADR13/ 

20 address lines; used to transmit the address of 
the memory location or I/O port to be accessed. 
The lines are labeled ADRO/ through ADR9/, 
ADRA/ through ADRF/ and ADRIO/ through 
ADR13/. ADR13/ is the most significant bit. 
8-bit masters use 16 address lines (ADRO/ - 
ADRF/) for memory addressing and 8 address 
lines (ADRO/ - ADR7/) for I/O port selection. 
16-bit masters use all twenty address lines for 
memory addressing and 12 address lines 
(ADRO/ - ADRB/) for I/O port selection. Thus, 
8-bit masters may address 64K bytes of memory 
and 256 I/O devices while 16-bit masters may 
address 1 megabyte of memory and 4096 I/O 
devices. (The 8086 CPU actually permits 16 
address bits to be used to specify I/O devices, 
the MULTIBUS specification, however, states 
that only the low order 12 address bits can be 
used to specify I/O ports.) In a 16-bit system, 
the ADRO/ line is used to indicate whether a low 
(even) byte or a high (odd) byte of memory or 
I/O space is being accessed in a word oriented 
memory or I/O device. 

BHEN/ 

Byte High Enable; the address control line 
which is used to specify that data will be trans- 
ferred on the high byte (DAT8/ - DATF/) of the 
MULTIBUS data lines. With current iSBC 
boards, this signal effectively specifies that a 
word (two byte) transfer is to be performed. This 
signal is used only in systems which incorporate 
sixteen bit memory or I/O modules. 



assigned the same memory addresses. INHl/ 
may also be used to allow memory mapped I/O 
devices to override RAM memory. 

INH2/ 

Inhibit ROM signal; prevents ROM memory 
devices from responding to the memory address 
on the system address bus. INH2/ effectively 
allows auxiliary ROM (e.g., a bootstrap pro- 
gram) to override ROM devices when ROM and 
auxiliary ROM memory are assigned the same 
memory addresses. INH2/ may also be used to 
allow memory mapped I/O devices to override 
ROM memory. 



Data Lines 

DATO/-DATF/ 

16 bidirectional data lines; used to transmit or 
receive information to or from a memory loca- 
tion or I/O port. DATF/ being the most signifi- 
cant bit. In 8-bit systems, only lines DATO/ - 
DAT7/ are used (DAT?/ being the most signi- 
ficant bit). In 16-bit systems, either 8 or 16 lines 
may be used for data transmission. 



Bus Priority Resolution Lines 

BCLK/ 

Bus clock; the negative edge (high to low) of 
BCLK/ is used to synchronize bus priority re- 
solution circuits. BCLK/ is asynchronous to the 
CPU clock. It has a 100 ns minimum period and 
a 35% to 65% duty cycle. BCLK/ may be slowed, 
stopped, or single stepped for debugging. 

CCLK/ 

Constant clock; a bus signal which provides a 
clock signal of constant frequency for unspeci- 
fied general use by modules on the system bus. 
CCLK/ has a minimum period of 100 ns and a 
35% to 65% duty cycle. 



INHl/ 

Inhibit RAM signal; prevents RAM memory 
devices from responding to the memory address 
on the system address bus. INHl/ effectively 
allows ROM memory devices to override RAM 
devices when ROM and RAM memory are 



BPRN/ 

Bus priority in signal; indicates to a particular 
master module that no higher priority module 
is requesting use of the system bus. BPRN/ is 
synchronized with BCLK/. This signal is not 
bused on the backplane. 
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BPRO/ 

Bus priority out signal; used with serial (daisy 
chain) bus priority resolution schemes. BPRO/ 
is passed to the BPRN/ input of the master 
module with the next lower bus priority. BPRO/ 
is synchronized with BCLK/. This signal is not 
bused on the backplane. 



BUSY/ 

Bus busy signal; an open collector line driven 
by the bus master currently in control to indicate 
that the bus is currently in use. BUSY/ prevents 
all other master modules from gaining control 
of the bus. BUSY/ is synchronized with BCLK/. 



BREQ/ 

Bus request signal; used with a parallel bus 
priority network to indicate that a particular 
master module requires use of the bus for one 
or more data transfers. BREQ/ is synchronized 
with BCLK/. This signal is not bused on the 
backplane. 

CBRQ/ 

Common bus request; an open-collector line 
which is driven by all potential bus masters 
and is used to inform the current bus master 
that another master wishes to use the bus. If 
CBRQ/ is high, it indicates to the bus master 
that no other master is requesting the bus, and 
therefore, the present bus master can retain the 
bus. This saves the bus exchange overhead for 
the current master. 

Information Transfer Protocol Lines 

A bus master provides separate read/write 
command signals for memory and I/O devices: 
MRDC/, MWTC/, lORC/ and lOWC/, as ex- 
plained below. When a read/write command is 
active, the address signals must be stabilized at all 
slaves on the bus. For this reason, the protocol 
requires that a bus master must issue address 
signals (and data signals for a write operation) at 
least 50 ns ahead of issuing a read/write command 
to the bus, initiating the data transfer. The bus 
master must keep address signals unchanged until 
at least 50 ns after the read/write command is 
turned off, terminating the data transfer. 

A bus slave must provide an acknowledge signal to 



the bus master in response to a read or write 
command signal. 

MRDC/ 

Memory read command; indicates that the 
address of a memory location has been placed 
on the system address lines and specifies that 
the contents (8 or 16 bits) of the addressed 
location are to be read and placed on the system 
data bus. MRDC/ is asynchronous with respect 
to BCLK/. 

MWTC/ 

Memory write command; indicates that the 
address of a memory location has been placed 
on the system address lines and that data (8 or 
16 bits) has been placed on the system data bus. 
MWTC/ specifies that the data is to be written 
into the addressed memory location. MWTC/ is 
asynchronous with respect to BCLK/. 

lORC/ 

I/O read command; indicates that the address 
of an input port has been placed on the system 
address bus and that the data (8 or 16 bits) at 
that input port is to be read and placed on the 
system data bus. lORC/ is asynchronous with 
respect to BCLK/. 

lOWC/ 

I/O write command; indicates that the address 
of an output port has been placed on the system 
address bus and that the contents of the system 
data bus (8 or 16 bits) are to be output to the 
address port. lOWC/ is asynchronous with 
respect to BCLK/. 

XACK/ 

Transfer acknowledge signal; the required 
response of a slave board which indicates that 
the specified read/write operation has been 
completed. That is, data has been placed on, or 
accepted from, the system data bus lines. 
XACK/ is asynchronous with respect to BCLK/. 

Asynchronous Interrupt Lines 



INTO/ - INT7/ 
8 Multi-level, parallel interrupt request lines; 



1-49 



used with a parallel interrupt resolution net- 
work. INTO/ has the highest priority, while 
INT7/ has lowest priority. Interrupt lines 
should be driven with open collector drivers. 



INTA/ 

Interrupt acknowledge, an interrupt acknowl- 
edge line (INTA/), driven by the bus master, 
requests the transfer of interrupt information 
onto the bus from slave priority interrupt con- 
trollers (8259s or 8259As). The specific informa- 
tion timed onto the bus depends upon the 
implementation of the interrupt scheme. In 
general, the leading edge of INTA/ indicates 
that the address bus is active while the trailing 
edge indicates that data is present on the data 
lines. 



MULTIBUS P2 Signal Lines - The signals 
contained on the MULTIBUS P2 auxiliary con- 
nector are used primarily by optional power 
back-up circuitry for memory protection. P2 
signals are not bused on the backplane, and 
therefore, require a separate connector for each 
board using the P2 signals. Present iSBC boards 
have a slot in the card edge and should be used 
with a keyed P2 edge connector. Use of the P2 
signal lines is optional. 



sense latch is part of external power fail cir- 
cuitry and must be powered by the standby 
power source. 

PFSR/ 

Power fail sense reset, this line is used to reset 
the power fail sense latch (PFSN/). 

MPRO/ 

Memory protect] prevents memory operation 
during period of uncertain DC power, by in- 
hibiting memory requests. MPRO/ is driven 
by external power fail circuitry. 

ALE 

Address latch enable; generated by the CPU 
(8085 or 8086) to provide an auxiliary address 
latch. 



HALT/ 
Halt) indicates that the master CPU is halted. 



AUX RESET/ 

Auxiliary Reset) this externally generated sig- 
nal initiates a power-up sequence. 



ACLO 

AC Low; this signal generated by the power 
supply goes high when the AC line voltage 
drops below a certain voltage (e.g., 103v AC in 
115v AC line voltage systems) indicating D.C. 
power will fail in 3 msec. ACLO goes low when 
all D.C. voltages return to approximately 95% 
of the regulated value. This line must be pulled 
up by the optional standby power source, if one 
is used. 



WAIT/ 

Bus master wait state; this signal indicates 
that the processor is in a wait state. 



Reserved — - Several PI and P2 connector bus 
pins are unused. However, they should be regard- 
ed as reserved for dedicated use in future Intel 
products. 



PFIN/ 



Power fail interrupt; this signal interrupts the 
processor when a power failure occurs, it is 
driven by external power fail circuitry. 



IS 



Power Supplies — The power supply bus pins 
are detailed in Appendix A which contains the 
pin assignment of signals on the MULTIBUS 
backplane. 



PFSN/ 

Power fail sense; this line is the output of a 
latch which indicates that a power failure has 
occurred. It is reset by PFSR/. The power fail 



It is the designer's responsibility to provide 
adequate bulk decoupling on the board to avoid 
current surges on the power supply lines. It is also 
recommended that you provide high frequency 
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decoupling for the logic on your board. Values of 
22uF for +5v and +12v pins and lOuF for -5v and 
-12v pins are typical on iSBC boards. 



Operating Characteristics 

Beyond the definition of the MULTIBUS signals 
themselves, it is important to examine the 
operating characteristics of the bus. The AC 
requirements outline the timing of the bus signals 
and in particular, define the relationships between 
the various bus signals. On the other hand, the DC 
requirements specify the bus driver character- 
istics, maximum bus loading per board, and the 
pull-up/down resistors. 

The AC requirements are best presented by a 
discussion of the relevant timing diagrams. 
Appendix B contains a list of the MULTIBUS 
timing specifications. The following sections will 
discuss data transfers, inhibit operations, inter- 
rupt operations, MULTIBUS multi-master opera- 
tion and power fail considerations. 

Data Transfers — Data transfers on the MULTI- 
BUS system bus occur with a maximum band- 
width of 5 MHz for single or multiple read/write 
transfers. Due to bus arbitration and memory 
access time, a typical maximum transfer rate is 
often on the order of 2 MHz. 



Read Data 

Figure 1 shows the read operation AC timing 
diagram. The address must be stable (t as) ^^^ ^ 
minimum of 50 ns before command (lORC/ or 
MRDC/). This time is typically used by the bus 
interface to decode the address and thus provide 
the required device selects. The device selects 
establish the data paths on the user system in 
anticipation of the strobe signal (command) 
which will follow. The minimum command pulse 
width is 100 ns. The address must remain stable 
for at least 50 ns following the command (t^j^). 
Valid data should not be driven onto the bus prior 
to command, and must not be removed until the 
command is cleared. The XACK/ signal, which is 
a response indicating the specified read/write 
operation has been completed, must coincide or 
follow both the read access and valid data HdxO' 
XACK/ must be held until the command is cleared 
(tXAH). 
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Figure 1. Read AC Timing 



Write Data 

The write operation AC timing diagram is shown 
in Figure 2. During a write data transfer, valid 
data must be presented simultaneously with a 
stable address. Thus, the write data setup time 
(t£)g) has the same requirement as the address 
setup time (t^s)- ^^^ requirement for stable data 
both before and after command (lOWC/ or 
MWTC/) enables the bus interface circuitry to 
latch data on either the leading or trailing edge of 
command. 
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Figure 2. Write AC Timing 



Data Byte Swapping in 16-bit Systems 

A 16-bit master may transfer data on the MULTI- 
BUS data lines using 8-bit or 16-bit paths 
depending on whether a byte or word (2 byte) 
operation has been specified. (A word transfer 
specified with an odd I/O or memory address will 
actually be executed as two single byte transfers.) 
An 8-bit master may only perform byte transfers 
on the MULTIBUS data lines DATO/ - DAT7/. 

In order to maintain compatibility with older 
8-bit masters and slaves, a byte swapping buffer 
is included in all new 16-bit masters and 16-bit 
slaves. In the iSBC product line, all byte transfers 
will take place on the low 8 data lines DATO/ - 
DAT7/. Figure 3 contains a example of 8/16-bit 
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data driver logic for 16-bit master and slave 
systems. In the 8/16-bit system, there are three 
sets of buffers; the lower byte buffer which 
accesses DATO/ - DAT7/, the upper byte buffer 
which accesses DATS/ - DATF/, and the swap 
byte buffer which accesses the MULTIBUS data 
lines DATO/ - DAT?/ and transfers the data 
to/from the on-board data bus lines D8 - DF. 

Figure 4 summarizes the 8 and 16-bit data paths 
used for three types of MULTIBUS transfers. Two 
signals control the data transfers. 

Byte High Enable (BHEN/) active indicates that 
the bus is operating in sixteen bit mode, and 
Address Bit (ADRO/) defines an even or odd byte 
transfer address. 

On the first type of transfer, BHEN/ is inactive, 
and ADRO/ is inactive indicating the transfer of 
an even eight bit byte. The transfer takes place 
across data lines DATO/ - DAT7/. 

On the second type of transfer, BHEN/ is inactive, 
and ADRO/ is active indicating the transfer of a 
high (odd) byte. On this type of transfer, the odd 
(high) byte is transferred through the Swap Byte 
Buffer to DATO/ - DAT?/. This makes eight bit 
and sixteen bit systems compatible. 
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Figure 3. 8/16-Bit Data Drivers 
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Figure 4. 8/16-Bit Device Transfer Operation 
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The third type of transfer is a 16 bit (word) 
transfer. This is indicated by BHEN/ being 
active, and ADRO/ being inactive. On this type of 
transfer, the low (even) byte is transferred on 
DATO/ - DAT7/ and the high (odd) byte is 
transferred on DAT8/ - DATF/. 
Note that the condition when both BHEN/ and 
ADRO/ are active is not used with present iSBC 
boards. This condition could be used to transfer a 
high odd byte of data on DAT8/ - DATF/, thus 
eliminating the need for the swap byte buffer. 
However, this is not a recommended transfer type, 
because it eliminates the capability of communi- 
cating with 8-bit modules. 

Inhibit Operations — Bus inhibit operations are 
required by certain bootstrap and memory mapped 
I/O configurations. The purpose of the inhibit 
operation is to allow a combination of RAM, ROM, 
or memory mapped I/O to occupy the same 
memory address space. In the case of a bootstrap, 
it may be desirable to have both ROM and RAM 
memory occupy the same address space, selecting 
ROM instead of RAM for low order memory only 
when the system is reset. A system designed to use 



memory mapped I/O, which has actual memory 
occupying the memory mapped I/O address 
space, may need to inhibit RAM or ROM memory 
to perform its functions. 

There are two essential requirements for a success- 
ful inhibit operation. The first is that the inhibit 
signal must be asserted as soon as possible, within 
a maximum of 100 ns (td), after stable address. 
The second requirement for a successful inhibit 
operation is that the acknowledge must be delayed 
(txACKB) *^ allow the inhibited slave to ter- 
minate any irreversible timing operations in- 
itiated by detection of a valid command prior to its 
inhibit. 

This situation may arise because a command can 
be asserted within 50 ns after stable address (t^s) 
and yet inhibit is not required until 100 ns (tjj)) 
after stable address. The acknowledge delay time 
(txACKB) is a function of the cycle time of the 
inhibited slave memory. Inhibiting the iSBC 016 
RAM board, for example, requires a minimum of 
1.5 usee. Less time is typically needed to inhibit 
other memory modules. For example, the iSBC 104 
board requires 475 ns. 
Figure 5 depicts a situation in which both RAM 



r 



SLAVE A 
(RAM) 



SLAVES 
(PROM) 



DRIVER 
ENABLE/ 



DRIVER 
ENABLE/ 



READ DATA 



r 



k 




RAM XACK IF NOT INHIBITED 



_J 




r 



Figure 5. Inhibit Timing 
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and PROM memory have the same memory 
addresses. In this case, PROM inhibits RAM, 
producing the effect of PROM overriding RAM. 
After address is stable, local selects are generated 
•for both the PROM and the RAM. The PROM local 
select produces the INHl/ signal which then 
removes the RAM local select and its driver enable. 
Because the slave RAM has been inhibited after it 
had already begun its cycle, the PROM XACK/ 
must be delayed (tXACKB) until after the latest 
possible acknowledgement from the RAM 
(tXACKA)- 

Interrupt Operations — The MULTIBUS inter- 
rupt lines INTO/ - INT7/ are used by a MULTI- 
BUS master to receive interrupts from bus slaves, 
other bus masters or external logic such as power 
fail logic. A bus master may also contain internal 
interrupt sources which do not require the bus 
interrupt lines to interrupt the master. There are 
two interrupt implementation schemes used by 
bus interrupts, Non Bus Vectored Interrupts and 
Bus Vectored Interrupts. Non Bus Vectored 
Interrupts do not convey interrupt vector address 
information on the bus. Bus Vectored Interrupts 
are interrupts from slave Priority Interrupt Con- 
trollers (PICs) which do convey interrupt vector 



address information on the bus. 



Non Bus Vectored Interrupts 

Non Bus Vectored Interrupts are those interrupts 
whose interrupt vector address is generated by the 
bus master and do not require the MULTIBUS 
address lines for transfer of the interrupt vector 
address. The interrupt vector address is generated 
by the interrupt controller on the master and 
transferred to the processor over the local bus. The 
source of the interrupt can be on the master module 
or on other bus modules, in which case the bus 
modules use the MULTIBUS interrupt request 
lines (INTO/ - INT7/) to generate their interrupt 
requests to the bus master. When an interrupt 
request line is activated, the bus master performs it 
own interrupt operation and processes the inter- 
rupt. Figure 6 shows an example of Non Bus 
Vectored Interrupt implementation. 

Bus Vectored Interrupts 

Bus Vectored Interrupts (Figure 7) are those inter- 
rupts which transfer the interrupt vector address 
along the MULTIBUS address lines from the 
slave to the bus master using the INTA/ command 
signal for synchronization. 
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Figure 6. Non Bus Vectored Interrupt Implementation 
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Figure 7. Bus Vectored Interrupt Logic (With 2 INTA/ Timing Diagram) 



When an interrupt request from the MULTIBUS 
interrupt lines INTO/ - INT7/ occurs, the interrupt 
control logic on the bus master interrupts its 
processor. The processor on the bus master 
generates an INTA/ command which freezes the 
state of the interrupt logic on the MULTIBUS 
slaves for priority resolution. The bus master also 
locks (retains the bus between bus cycles) the 
MULTIBUS control lines to guarantee itself 
consecutive bus cycles. After the first INTA/ 
command, the bus master's interrupt control logic 
puts an interrupt code on to the MULTIBUS 
address lines ADR8/ - ADRA/. The interrupt code 
is the address of the highest priority active inter- 
rupt request line. At this point in the Bus Vectored 



Interrupt procedure, two different sequences could 
take place. The difference occurs, because the 
MULTIBUS specification can support masters 
which generate one additional INTA/ (8086 
masters) or two additional INTA/s (8080A and 
8085 masters). 

If the bus master generates one additional INTA/, 
this second INTA/ causes the bus slave interrupt 
control logic to transmit an interrupt vector 8-bit 
pointer on the MULTIBUS data lines. The vector 
pointer is used by the bus master to determine the 
memory address of the interrupt service routine. 

If the bus master generates two additional 
INTA/s, these two INTA/ commands allow the 
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bus slave to put a two byte interrupt vector address 
on to the MULTIBUS data lines (one byte for each 
INTA/). The interrupt vector address is used by 
the bus master to service the interrupt. 

The MULTIBUS specification provides for only 
one type of Bus Vectored Interrupt operation in a 
given system. Slave boards which have an 8259 
interrupt controller are only capable of 3 INTA/ 
operation (2 additional INTA/s after the first 
INTA/). Slave boards with the 8259A interrupt 
controller are capable of either 2 INTA/ or 3 
INTA/ operation. All slave boards in a given 
system must operate in the same way (2 INTA/s or 
3 INTA/s) if Bus Vectored Interrupts are to be 
used. However, the MULTIBUS specification 
does provide for Bus Vectored Interrupts and Non 
Bus Vectored Interrupts in the same system. 

MULTIBUS Multi-Master Operation — The 

MULTIBUS system bus can accommodate several 
bus masters on the same system, each one taking 
control of the bus as it needs to affect data trans- 
fers. The bus masters request bus control through 
a bus exchange sequence. 

Two bus exchange priority resolution techniques 
are discussed, a serial technique and a parallel 
technique. Figures 8 and 9 illustrate these two 
techniques. The bus exchange operation dis- 
cussed later is the same for both techniques. 

Serial Priority Technique 

Serial priority resolution is accomplished with a 
daisy chain technique (see Figure 8). The priority 
input (BPRN/) of the highest priority master is 
tied to ground. The priority output (BPRO/) of the 



highest priority master is then connected to the 
priority input (BPRN/) of the next lower priority 
master, and so on. Any master generating a bus 
request will set its BPRO/ signal high to the next 
lower priority master. Any master seeing a high 
signal on its BPRN/ line will sets its BPRO/ line 
high, thus passing down priority information to 
lower priority masters. In this implementation, 
the bus request line (BREQ/) is not used outside of 
the individual masters. A limited number of 
masters can be accommodated by this technique, 
due to gate delays through the daisy chain. Using 
the current Intel MULTIBUS controller chip on 
the master boards up to 3 masters may be accom- 
modated if a BCLK/ period of 100 ns is used. If 
more bus masters are required, either BCLK/ must 
be slowed or a parallel priority technique used. 

Parallel Priority Technique 

In the parallel priority technique, the priority is 
resolved in a priority resolution circuit in which 
the highest priority BREQ/ input is encoded with 
a priority encoder chip (74148). This coded value is 
then decoded with a priority decoder chip (74S138) 
to activate the appropriate BPRN/ line. The 
BPRO/ lines are not used in the parallel priority 
scheme. However, since the MULTIBUS back- 
plane contains a trace from the BPRN/ signal of 
one card slot to the BPRO/ signal of the adjacent 
lower card slot, the BPRO/ must be disconnected 
from the bus on the board or the backplane trace 
must be cut. A practical limit of sixteen masters 
can be accommodated using the parallel priority 
technique due to physical bus length limitations. 
Figure 9 contains the schematic for a typical 
parallel resolution network. Note that the parallel 
priority resolution network must be externally 
supplied. 
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Figure 8. Serial Priority Teclinique 



1-56 



NO. 8 
PRIORITY 
(LOWEST) 
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MULTIBUS Exchange Operation — A timing 
diagram for the MULTIBUS exchange operation 
is shown in Figure 10. This implementation 
example uses a parallel resolution scheme, how- 
ever, the timing would be basically the same for 
the serial resolution scheme. 

In this example, master A has been assigned a 
lower priority than master B, The bus exchange 
occurs because master B generates a bus request 
during a time when master A has control of the 
bus. 

The exchange process begins when master B 
requires the bus to access some resource such as an 
I/O or memory module while master A controls the 
bus. This internal request is synchronized with 
the trailing edge (high to low) of BCLK/ to 
generate a bus request (BREQ/). The bus priority 
resolution circuit changes the BPRN/ signal from 
active (low) to inactive (high) for master A and 
from inactive to active for master B. Master A 
must first complete the current bus command if 
one is in operation. After master A completes the 
command, it sets BUSY/ inactive on the next 
trailing edge of BCLK/. This allows the actual bus 
exchange to occur, because master A has relin- 
quished control of the bus, and master B has been 
granted its BPRN/. During this time, the drivers 



for master A are disabled. Master B must take 
control of the bus with the next trailing edge of 
BCLK/ to complete the bus exchange. Master B 
takes control by activating BUSY/ and enabling 
its drivers. 

It is possible for master A to retain control of the 
bus and prevent master B from getting control. 
Master A activates the Bus Override (or Bus Lock) 
signal which keeps BUSY/ active allowing con- 
trol of the bus to stay with master A. This 
guarantees a master consecutive bus cycles for 
software or hardware functions which require 
exclusive, continuous access to the bus. 

Note that in systems with only a single master it is 
necessary to ground the BPRN/ pin of the master, 
if slave boards are to be accessed. In single board 
systems which use a CPU board capable of Bus 
Vectored Interrupt operation, the BPRN/ pin must 
also be grounded. 

In a single master system bus transfer efficiency 
may be gained if the BUS OVERRIDE signal is 
kept active continuously. This permits the master 
to maintain control of the bus at all times, there- 
fore saving the overhead of the master reacquiring 
the bus each time it is needed. 

The CBRQ/ line may be used by a master in 
control of the bus to determine if another master 
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Figure 10. Bus Control Exchange Operation 



requires the bus. If a master currently in control of 
the bus sees the CBRQ/ line inactive, it will 
maintain control of the bus between adjacent bus 
accesses. Therefore, when a bus access is required, 
the master saves the overhead of reacquiring the 
bus. If a current bus master sees the CBRQ/ line 
active, it will then relinquish control of the bus 
after the current bus access and will contend for 
the bus with the other master(s) requiring the bus. 
The relative priorities of the masters will deter- 
mine which master receives the bus. 



Note that except for the BUS OVERRIDE state, no 
single master may keep exclusive control of the 
bus. This is true because it is impossible for the 
CPU on a blaster to require continuous access to 
the bus. Other lower priority masters will always 
be able to gain access to the bus between accesses 
of a higher priority master. 

Power Fail Considerations — The MULTIBUS 
P2 connector signals provide a means of handling 
power failures. The circuits required for power 
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Figure 11. Power Fail Timing Sequence 



failure detection and handling are optional and 
must be supplied by the user. Figure 11 shows 
the timing of a power fail sequence. 

The power supply monitors the AC power level. 
When power drops below an acceptable value, the 
power supply raises ACLO which tells the power 
fail logic that a minimum of three milliseconds will 
elapse before DC power will fall below regulated 
voltage levels. The power fail logic sets a sense 
latch (PFSN/) and generates an interrupt (PFIN/) 
to the processor so the processor can store its 
environment. After a 2.5 millisecond timeout, the 
memory protect signal (MPRO/) is asserted by the 
power fail logic preventing any memory activity. 
As power falls, the memory goes on standby 
power. Note that the power fail logic must be 
powered from the standby source. 

As the AC line revives, the logic voltage level is 
monitored by the power supply. After power has 
been at its operating level for one millisecond 
minimum, the power supply sets the signal ACLO 
low, beginning the restart sequence. First, the 
memory protect line (MPRO/) then the initialize 
line (INIT/) become inactive. The bus master now 
starts running. The bus master checks the power 
fail latch (PFSN/) and, if it finds it set, branches to 



a power up routine which resets the latch (PFSR/), 
restores the environment, and resumes execution. 

Note that INIT/ is activated only after DC power 
has risen to the regulated voltage levels and must 
stay low for five milliseconds minimum before the 
system is allowed to restart. Alternatively, INIT/ 
may be held low through an open collector device 
by MPRO/. 

How the power failure equipment is configured is 
left to the system designer. The backup power 
source may be batteries located on the memory 
boards or more elaborate facilities located off- 
board. The location of the power fail logic 
determines which MULTIBUS power fail lines are 
used. Pins on the P2 connector have been specified 
for the power failure functions for use as needed. 

To further clarify the location and use of the power 
fail circuitry, an example of a typical power fail 
system block diagram is shown in Figure 12. A 
single board computer and a slave memory board 
are contained in the system. It is desired to power 
the memory circuit elements of the memory board 
from auxiliary power. The single board computer 
will remain on the main power supply. To ac- 
complish this, user supplied power fail logic and 
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DC Requirements — The drive and load charac- 
teristics of the bus signals are listed in Appendix 
C. The physical locations of the drivers and loads, 
as well as the terminating resistor value for each 
bus line, are also specified. Appendix D contains 
the MULTIBUS power specifications. 



MULTIBUS™ Slave Interface 
Circuit Elements 



*USER SUPPLIED 



Figure 12. Typical Power Fail System Block Diagram 



There are three basic elements of a slave bus 
interface: address decoders, bus drivers, and 
control signal logic. This section discusses each of 
these elements in general terms. A description of a 
detailed implementation of a slave interface is 
presented in a later section of this application note. 



an auxiliary power supply have been included in 
the system. 

The single board computer is powered from the PI 
power lines and accesses the P2 signal lines 
PFIN/, PFSN/ and PFSR/ (only the P2 signal 
lines used by a particular functional block are 
shown on the block diagram). The PFSR/ line is 
driven from two sources: a front panel switch and 
the single board computer. The front panel switch 
is used during normal power-up to reset the power 
fail sense latch. The single board computer uses 
the PFSR/ line to reset the latch during a power-up 
sequence after a power failure. Current single 
board computers must access the PFSN/ and 
PFSR/ signals either directly with dedicated 
circuitry and a P2 pin connection or through the 
parallel I/O lines with a cable connection from the 
parallel I/O connector to the P2 connector. 



The slave memory board uses both the PI and P2 
power lines, the P2 power lines are used (at all 
times) to power the memory circuit elements and 
other support circuits, the PI power lines power all 
other circuitry. In addition, the MPRO/ line is 
input and used to sense when memory contents 
should be protected. 



The power fail logic contains the power fail sense 
latch, and uses the PFSR/ and ACLO lines for 
inputs and the PFIN/ PFSN/, and MPRO/ lines 
for outputs. The power fail logic must be powered 
by the P2 power lines. 



Address Decoding — This logic decodes the 
appropriate MULTIBUS address bits into RAM 
requests, ROM requests, or I/O selects. Care must 
be taken in the design of the address decode logic 
to ensure flexibility in the selection of base address 
assignments. Without this flexibility, restrictions 
may be placed upon various system configura- 
tions. Ideally, switches and jumper connections 
should be associated with the decode logic to 
permit field modification of base address assign- 
ments. 

The initial step in designing the address decode 
portion of a MULTIBUS interface is to determine 
the required number of unique address locations. 
This decision is influenced by the fact that 
address decoding is usually done in two stages. 
The first stage decodes the base address, pro- 
ducing an enable for the second stage which 
generates the actual device selects for the user 
logic. A convenient implementation of this two 
stage decoding scheme utilizes a pair of decoders 
driven by the high order bits of the address for the 
first stage and a second decoder for the low order 
bits of the address bus. This technique forces the 
number of unique address locations to be a power 
of two, based at the address decoded by the first 
stage. Consider the scheme illustrated in Figure 
13. 



As shown in Figure 13, the address bits A4 - Ab are 
used to produce switch selected outputs of the first 
stage of decoding. The 1 out of 8 binary decoders 
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have been used. The top decoder decodes address 
Unes A4 - A7, and the bottom decoder decodes 
address lines Ag - Ag. If only address lines Aq - A 7 
are being used for device selection, as in the case of 
I/O port selection in 8-bit systems, the bottom 
decoder may be disabled by setting switch S2 to the 
ground position. Address lines A7 and Ag drive 
enable inputs E2 or E3 of the decoders. The 
address lines Aq - A3 enter the second stage 
address decoder to produce 8 user device selects. 
The second stage decoder must first be enabled by 
an address that corresponds to the switch-selected 
base address. 



devices are simultaneously selected, and because 
the addressing within such a system is restricted 
by the extent of the address space occupied by such 
a scheme. 



Data Bus Drivers — For user designed logic 
which simply receives data from the MULTIBUS 
data lines, this portion of the bus interface logic 
may only consist of buffers. Buffers are required 
to ensure that maximum allowable bus loading is 
not exceeded by the user logic. 



Address decoding must be completed before the 
arrival of a command. Since the command may 
become active within 50 ns after stable address, 
the decode logic should be kept simple with a 
minimal number of layers of logic. Furthermore, 
the timing is extremely critical in systems which 
make use of the inhibit lines. 

A linear or unary select scheme in which no binary 
encoding of device address (e.g., address bit Aq 
selects device 0, address bit Ai selects device 1, 
etc.) is performed is not recommended because the 
scheme offers no protection in case multiple 
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Figure 13. Two Stage Decoding Scheme 



In systems where the user designed logic must 
place data onto the MULTIBUS data lines, three- 
state drivers are required. These drivers should be 
enabled only when a memory read command 
(MRDC/) or an I/O read command (lORC/) is 
present and the module has been addressed. 

When both the read and write functions are re- 
quired, parallel bidirectional bus drivers (e.g., Intel 
8226, 8287, etc.) are used. A note of caution must be 
included for the designer who uses this type of 
device. A problem may arise if data hold time 
requirements must be satisfied for user logic 
following write operations. When bus commands 
are used to directly produce both the chip select for 
the bidirectional bus driver and a strobe to a latch 
in the user logic, removal of that signal may not 
provide the user's latch with adequate data hold 
time. Depending on the specifics of the user logic, 
this problem may be solved by permanently 
enabling the data buffer's receiver circuits and 
controlling only the direction of the buffers. 



Control Signal Logic -— The control signal logic 
consists of the circuits that forward the I/O and 
memory read/ write commands to their respective 
destinations, provide the bus with a transfer 
acknowledge response, and drive the system 
interrupt lines. 



Bus Command Lines 

The MULTIBUS information transfer protocol 
lines (MRDC/, MWTC/, lORD/. and lOWC/) 
should be buffered by devices with very high speed 
switching. Because the bus DC requirements 
specify that each board may load these lines with 
2.0 mA, Schottky devices are recommended. LS 
devices are not recommended due to their poor 
noise immunity. The commands should be gated 
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with a signal indicating the base address has been 
decoded to generate read and write strobes for the 
user logic. 



Transfer Acknowledge Generation 

The user interface transfer acknowledge genera- 
tion logic provides a transfer acknowledge re- 
sponse, XACK/, to notify the bus master that write 
data provided by the bus master has been accepted 
or that read data it has requested is available on 
the MULTIBUS data lines. XACK/ allows the bus 
master to conclude its current instruction. 

Since XACK/ timing requirements depend on both 
the CPU of the bus master and characteristics of 
the user logic, a circuit is needed which will provide 
a range of easily modified acknowledge responses. 

The transfer acknowledge signals must be driven 
by three-state drivers which are enabled when the 
bus interface is addressed and a command is 
present. 



Interrupt Signal Lines 

The asynchronous interrupt lines must be driven 
by open collector devices with a minimum drive of 
16 mA. 

In a typical Non Bus Vectored Interrupt system, 
logic must be provided to assert and latch-up an 
interrupt signal. In addition to driving the 
MULTIBUS interrupt lines, the latched interrupt 
signal would be read by an I/O operation such as 
reading the module's status. The interrupt signal 
would be cleared by writing to the status register. 



III. MULTIBUSTM SLAVE DESIGN 
EXAMPLE 

A MULTIBUS slave design example has been 
included in this application note to reinforce the 
theory previously discussed. The design example 
is of general purpose I/O slave interface. This 
design example could easily be modified to be used 
as a slave memory interface by buffering the 
address signals and using the appropriate 
MULTIBUS memory commands. In addition, to 
help the reader better understand an application 
for an I/O slave interface, two Intel 8255A Parallel 
Peripheral Interface (PPI) devices are shown con- 
nected to the slave interface. 

The design example is shown in both 8/16-bit 
version and an 8-bit version. The 8/16-bit version 



is an I/O interface which will permit a 16-bit 
master to perform 8 or 16 bit data transfers. 8-bit 
masters may also use the 8/16-bit version of the 
design example to perform 8-bit data transfers. 

The 8-bit version of the design example may be 
used by both 8 or 16-bit masters, but will only 
perform 8-bit data transfers. It does not contain 
the circuitry required to perform 16-bit data 
transfers. 

Both the 8/16-bit version and the 8-bit version of 
the design example were implemented on an iSBC 
905 prototype board. The schematics for each of 
the examples are given in Appendices F and G. 



Functional/ Programming Characteristics 

This section describes the organization of the 
slave interface from two points of view, the 
functional point of view and the programming 
characteristics. First, the principal functions 
performed by the hardware are identified and the 
general data flow is illustrated. This point of view 
is intended as an introduction to the detailed 
description provided in the next section; Theory of 
Operation. In the second point of view, the 
information needed by a programmer to access the 
slave is summarized. 



Functional Description — The function of this 
I/O slave is to provide the bus interface logic for 
general purpose I/O functions and for two Intel 
8255A Parallel Peripheral Interface (PPI) devices. 
Eight device selects (port addresses) are available 
for general purpose I/O functions. One of these 
device select lines is used to read and reset the state 
of an interrupt status flip-flop, the other seven 
device selects are unused in this design. An 
additional eight I/O device port addresses are 
used by the two 8255A devices; four I/O port 
addresses per 8255A (three I/O port address for 
the three parallel ports A, B, and C and the fourth 
I/O port address for the device control register). 

Figure 14 contains a functional block diagram of 
the slave design example. This block diagram 
shows the fundamental circuit elements of a bus 
slave: bidirectional data bus drivers/receivers, 
address decoding logic and bus control logic. Also 
shown is the address decoding logic for the low 
order four bits, the interrupt logic which is selected 
by this decoding logic, and the two 8255A devices. 
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Figure 14. MULTIBUS"" Slave Design Example 
Functional Block Diagram 



Programming Characteristics ■— The slave 
design example provides 16 I/O port addresses 
which may be accessed by user software. The 
base address of the 16 contiguous port addresses 
is selected by wire wrap connections on the proto- 
type board. The wire wrap connections specify 
address bits ADR4/ - ADRB/. They allow the 
selection of a base address on any 16 byte 
boundary. Twelve address bits (ADRO/ - ADRB/) 
are used since 16-bit (8086 based) masters use 12 
bits to specity I/O port addresses. If an 8 bit (8080 
or 8085 based) master is used with this slave board, 
the high order address bits (ADR8/ - ADRB/) must 
not be used by the decoding circuits; a wire wrap 
jumper position (ground position) is provided for 
this. 

The 16 I/O port addresses are divided into two 
groups of 8 port addresses by decoding address line 
ADR3/. Port addresses XXO - XX7 are used for 
general I/O functions (XX indicates any hexi- 
decimal digit combination). Port address XXO is 
used for accessing the interrupt status flip-flop and 



port addresses XXI - XX7 are not used in this 
example. Port addresses XX8 - XXF are used for 
accessing the PPIs. If port addresses XX8 - XXF 
are selected, then ADRO/ is used to specify which 
of two PPIs are selected. If the address is even 
(XX8, XXA, XXC, or XXE) then one PPI is selected. 
If the address is odd (XX9, XXB, XXD, or XXF), 
then the other PPI is selected. ADRl/ and ADR2/ 
are connected directly to the PPIs. Table 1 
summarizes the I/O port addresses of the slave 
design example. Note that if a 16-bit master is 
used, it is possible to access the slave in a byte or 
word mode. If word access is used with port 
address XX8, XXA, XXC, or XXE, then 16 bit 
transfers will occur between the PPIs and the 
master. These 16 bit transfers occur because an 
even address has been specified and the MULTI- 
BUS BHEN/ signal indicates that a 16-bit 
transfer is requested. 

Theory of Operation 

In the preceding section, each of the slave design 
example functional blocks was identified and 
briefly explained. This section explains how these 
functions are implemented. For detailed circuit 
information, refer to the schematics in Appendices 
F and G. The schematic in Appendix F is on a 
foldout page so that the following text may easily 
be related to the schematic. 

The discussion of the theory of operation is divided 
into five segments, each of which discusses a 
different function performed by the MULTIBUS 
slave design example. The five segments are: 

1. Bus address decoding 

2. Data buffers 

3. Control signals 

4. Interrupt logic 

5. PPI operation 

Each of these topics are discussed with regard to 
the 8/16-bit version of the design example; 
followed by a discussion of the circuit elements 
which are required by the 8-bit version of the 
interface. 



Bus Address Decoding — Bus address decoding 
is performed by two 8205 1 out of 8 binary decoders. 
One decoder (A3) decodes address bits ADR8/ - 
ADRB/ and the second decoder (A2) decodes 
address bits ADR4/ - ADR7/. The base address 
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Table 1 
SLAVE DESIGN EXAMPLE PORT ADDRESSES 



I/O PORT ADDRESS 


READ 


WRITE 


BYTE ACCESS 






XXO 

XXI - XX7 

XX8 

XX9 

XXA 

XXB 

XXC 

XXD 

XXE 

XXF 


Bit = Interrupt Status 
Unused 

Parallel Port A, Even PPI 
Parallel Port A, Odd PPI 
Parallel Port B, Even PPI 
Parallel Port B, Odd PPI 
Parallel Port C, Even PPI 
Parallel Port C, Odd PPI 
Illegal Condition 
Illegal Condition 


Reset Interrupt Status 
Unused 

Parallel Port A, Even PPI 
Parallel Port A, Odd PPI 
Parallel Port B, Even PPI 
Parallel Port B, Odd PPI 
Parallel Port C, Even PPI 
Parallel Port C, Odd PPI 
Control, Even PPI 
Control, Odd PPI 


WORD ACCESS 






XXO 

XX2 - XX6 

XXB 

XXA 

XXC 

XXE 


Bit = Interrupt Status 

Unused 

Parallel Port A, Even and Odd PPIs 

Parallel Port B, Even and Odd PPIs 

Parallel Port C, Even and Odd PPIs 

Illegal Condition 


Reset Interrupt Status 

Unused 

Parallel Port A, Even and Odd PPIs 

Parallel Port B, Even and Odd PPIs 

Parallel Port C, Even and Odd PPIs 

Control, Even and Odd PPIs 


XX = Any hex digits, assigned by jumpers; XX defines the base address. 



selected is determined by the position of wire wrap 
jumpers. The outputs of the two decoders are 
ANDed together to form the BASE ADR SELECT/ 
signal. This signal specifies the base address 
for a group of 16 I/O ports. Using the wire wrap 
jumper positions shown in the schematic, a base 
address of E3 has been selected. Therefore, this 
MULTIBUS slave board will respond to I/O port 
addresses in the E30 - E3F range. 



If this slave board is to be used with 8-bit MULTI- 
BUS masters, the high order address bits must not 
be decoded. Therefore, the wire wrap jumper 
which selects the output of decoder A3 must be 
placed in the top (ground) position (pin 10 of gate 
A9 to ground). 

The low order 4 address lines (ADRO/ - ADR3/) are 
buffered and inverted using 74LS04 inverters. 
These address lines are input to an 8205 for 
decoding a chip select for the interrupt logic; the 
address lines are also used directly by the PPIs. 
LS-Series logic is required for buffering to meet the 
MULTIBUS specification for Ijl (low level input 



current). S-Series or standard series logic will not 
meet this specification. 

Address decoder A4 is used to decode addresses 
E30 - E37. The CSO/ output of this decoder is used 
to select the interrupt logic, thus I/O port address 
E30 is used to read and reset the interrupt latch. 
The remaining outputs from decoder A4 (CSl/ - 
CS7/) are not used in this example. They would 
normally be used to select other functions in a 
slave board with more capability. Note that in the 
schematic shown in Appendix G for the 8-bit 
version of this slave design example, the high 
order (ADR8/ - ADRB/) address decoder is not 
included and the BHEN/ signal is not used. 



Data Buffers — Intel 8287 8-bit parallel bi- 
directional bus drivers are used for the MULTI- 
BUS data lines DATO/ - DATE/. In the 8/16-bit 
version of the slave board, three 8287 drivers 
are used. 

When an 8-bit data transfer is requested, either 
driver A5, which is connected to on-board data 
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lines DO - D7, or driver A6, which is connected to 
on-board data lines D8 - DF, is used. If a byte 
transfer is requested from an even address, driver 
A5 will be selected. If a byte transfer from an odd 
address is requested, driver A6 will be selected. All 
byte transfers take place on MULTIBUS data 
lines DATO/ - DAT7/. When a word (16-bit) 
transfer is requested from an even address, drivers 
A5 and A7 will be used. Note that if a user program 
requests a word transfer from an odd address, 
16-bit masters in the iSBC product line will 
actually perform two byte transfer requests. 

The logic which determines the chip selection 
(8287 input signal OE, output enable) signals for 
the bus drivers uses the low order address bit 
(ADRO/) and the buffered Byte High Enable 
signal (BHENBL/). Note that the MULTIBUS 
signal BHEN/ has been buffered with an 74LS04 
inverter. This is done to meet the bus address line 
loading specification. The SWAP BYTE/ signal 
which is generated is qualified by the BD ENBL/ 
signal and used to select the bus drivers. 

The steering pin for the 8287 drivers is labelled T 
(transmit) and is driven by the signal RD. When 
an input (read) request is active or when neither a 
read or write command is being serviced, the 
direction of data transfer of the 8287 will be set for 
B to A. 

The 8287 drivers are set to point IN (direction B to 
A) when no MULTIBUS I/O transfer command is 
being serviced for two reasons. First, if the driver 
were pointed OUT (direction A to B) and a write 
command occured, it would be necessary to turn 
the buffers IN and set the OE (output enable) 
signal active before the data could be transferred 
to the on-board bus. A possibility of a "buffer- 
fight" could occur in some designs if theOE signal 
permitted an 8287 to drive the MULTIBUS data 
lines momentarily before the steering signal could 
switch the direction of the 8287. In this case, both 
the MULTIBUS master and the slave would be 
driving the data lines; this is not recommended. 
(In this particular design, the steering signal will 
always stabilize before the OE signal becomes 
active.) 

The second reason the driver is pointing IN when 
no command is present is due to the "data valid 
after WRITE" requirements of the 8255As. The 
8255A requires that data remain on its data lines 
for 30 ns after the WRITE command (WR at the 
8255A) is removed. This requirement will be met if 
the direction of the 8287 drivers is not switched 



when the MULTIBUS lOWC/ signal is removed 
(WRT/ could have been used to steer the 8287 
instead of RD); and if the capacitance of the on- 
board data bus lines is sufficient to hold the data 
values on the bus after the 8287 OE signal and the 
8255A PPI WRT/ signal go inactive. The on-board 
data bus may easily be designed such that the 
capacitance of the lines is sufficient to meet the 30 
ns data hold time requirement. In addition, the 
current leakage of all devices connected to the on- 
board bus must be kept small to meet the 30 ns data 
hold time requirement. 

The 8-bit version of this design example uses only 
one 8287 instead of the three required by the 8/16- 
bit version. The logic required to control the swap 
byte buffer is also not necessary. The chip select 
signal used for the 8287 is the BD ENBL/ signal. 



Control Signals - The MULTIBUS control 
signals used by this slave design example are 
lORC/, lOWC/, and XACK/. lORC/ andlOWC/ 
are qualified by the BASE ADR SELECT/ signal 
to form the signals RD and WRT. RD and WRT 
are used to drive the interrupt logic, the PPI logic 
and the XACK/ (transfer acknowledge) logic. 

For the XACK/ logic RD and WRT are ORed to 
form the BD ENBL/ signal which is inverted and 
used to drive the CLEAR pin of a shift register. 
When the slave board is not being accessed, the 
CLEAR pin of the shift register will be low (BD 
ENBL/ is high). This causes the shift register to 
remain cleared and all outputs of the shift register 
will be low. When the slave board is accessed, the 
CLEAR pin will be high, and the A and B inputs 
(which are high) will be clocked to the output pins 
by CCLK/. To select a delay for the XACK/ signal, 
a jumper must be installed from one of the shift 
register output pins to the 8089 tri-state driver. 
Each of the shift register output pins select an 
integer multiple of CCLK/ periods for the signal 
delay. Since the CCLK/ signal is asynchronous, 
the actual delay selected may only be specified 
with a tolerance of one CCLK/ period. In this 
example a delay of 3 - 4 CCLK/ periods was 
selected; with a CCLK/ period of 100 ns, the 
XACK/ delay would occur somewhere within the 
range of 300 - 400 ns from the time when the 
CLEAR signal goes high. 

The control signal logic used in the 8-bit version of 
the slave design example is identical to the logic 
used in the 8/16-bit version. 
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Interrupt Logic — The interrupt logic uses a 
74S74 flip-flop to latch an asynchronous interrupt 
request from some external logic. The Q output 
of the INTERRUPT REQUEST LATCH is output 
through an open collector gate to one of the 
MULTIBUS interrupt lines. The state of the 
INTERRUPT REQUEST LATCH is transferred 
to the INTERRUPT STATUS LATCH when a 
read command is performed on I/O port BASE 
ADDRESS+0 (E30 for the jumper configuration 
shown). The Q output of INTERRUPT STATUS 
LATCH is used to drive data line DO of the on- 
board data bus by using an 8089 tri-state driver. 
If a user program performs an INPUT from I/O 
port E30, data bit will be set to 1 if the INTER- 
RUPT REQUEST LATCH is set. 

The purpose of INTERRUPT STATUS LATCH is 
to minimize the possibility of the asynchronous 
interrupt occuring while the interrupt status is 
being read by a bus master. If the latch was not 
included in the design and an asynchronous inter- 
rupt did occur while a bus master is reading 
MULTIBUS data line DATO/, a data buffer on the 
master could go into a meta-stable state. By 
adding the extra latch, which is clocked by the 
lORD/ command for I/O port E30, the possibility 
of data line DATO/ changing during a bus master 
read operation is eliminated. 

The INTERRUPT REQUEST LATCH is cleared 
when a user program performs an OUTPUT to I/O 
portESO. 

This interrupt structure assumes that several 
interrupt sources may exist on the same MULTI- 
BUS interrupt line (for example, INT3/). When the 
MULTIBUS master gets interrupted, it must poll 
the possible sources of the interrupt received and 
after determining the source of the interrupt, it 
must clear the INTERRUPT REQUEST LATCH 
for that particular interrupt source. 

The interrupt logic for the 8-bit version of the 
design example is identical to the interrupt logic of 
the 8/16-bit version of the design example. 



PPI Operation — Two 8255 A Parallel Peripheral 
Interface (PPI) devices are shown interfaced to 
the slave design example logic. One PPI is con- 
nected to the on-board data bus lines DO - D7 and 
is addressed with the even I/O port addresses 
E38, E3A, E3C, and E3E. The second PPI is 
connected to data bus lines D8 - DF and is address- 
ed with the odd I/O port addresses E39, E3B, 



E3D, and E3F. The even or odd I/O port selection 
is controlled by using the ADRO address line in 
the chip select term of the PPIs. In addition, the 
odd PPI (All) is selected when the BHENBL 
term is high. This occurs when the MULTIBUS 
signal BHEN/ is low indicating that a word 
(16-bit) I/O instruction is being executed. When 
a word I/O instruction is executed, both PPIs will 
perform the I/O operation specified. 

The specifications of the 8255A device state that 
the address lines AO and Al and the chip select 
lines must be stable before the RD or WR lines are 
activated. The MULTIBUS specification address 
set-up time of 50 ns and the short gate propagation 
delays in this design assure that the address lines 
are stable before RD or WR are active. 

The data hold requirements of the 8255A were 
discussed in a previous section. The 8255A speci- 
fication states that data will be stable on the data 
bus lines a maximum of 250 ns after a READ 
command. This specification was used to select 
the delay for the XACK/ signal. 

The PPI operation for the 8-bit version of the 
design example is slightly different than that used 
for the 8/16-bit version. The chip select signal for 
the bottom PPI does not use the BHENBL term 
since 16-bit data transfers are not possible with an 
8-bit I/O slave board. Also, the chip select and 
address signals have been swapped so the top PPI 
occupies I/O address range X8 - XB, and the 
bottom PPI occupies I/O address range XC - XF (X 
is the base address of the 8-bit version). This 
swapping of the address lines was not necessary; 
however, it was thought to be more convenient to 
access the PPIs in two groups of 4 contiguous I/O 
port addresses. 



IV. SUMMARY 

This application note has shown the structure of 
the Intel MULTIBUS system bus. The structure 
supports a wide range of system modules from the 
Intel OEM Microcomputer Systems product line 
that can be extended with the addition of user 
designed modules. Because the user designed 
modules are no doubt unique to particular applica- 
tions, a goal of this application note has been to 
describe in detail the singular common element - 
the bus interface. Material has also been 
presented to assist the systems designer to under- 
standing the bus functions so that successful 
systems integration can be achieved. 
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APPENDIX A 
PIN ASSIGNMENT OF BUS SIGNALS ON MULTIBUS BOARD PI CONNECTOR 





PIN 


(COMPONENTSIDE) 


PIN 


(CIRCUIT SIDE) 


MNEMONIC 


DESCRIPTION 


MNEMONIC 


DESCRIPTION 


POWER 
SUPPLIES 


1 
3 
5 

7 
9 
11 


GND 
+ 5V 
+ 5V 
+ 12V 
-5V 
GND 


Signal GND 
+ 5Vdc 
+ 5Vdc 
+12Vdc 
-5Vdc 
Signal GND 


2 
4 
6 
8 

10 
12 


GND 
+ 5V 
+ 5V 
+ 12V 
-5V 
GND 


Signal GND 
+ 5Vdc 
+ 5Vdc 
+12Vdc 
-5Vdc 
Signal GND 


BUS 
CONTROLS 


13 
15 
17 
19 
21 
23 


BCLK/ 

BPRN/ 

BUSY/ 

MRDC/ 

lORC/ 

XACK/ 


Bus Clock 
BusPri. In 
Bus Busy 
Mem Read Cmd 
I/O Read Cmd 
XFER Acknowledge 


14 
16 
18 
20 
22 
24 


INIT/ 

BPRO/ 

BREQ/ 

MWTC/ 

lOWC/ 

INH1/ 


Initialize 
Bus Ph. Out 
Bus Request 
Mem Write Cmd 
I/O Write Cmd 
Inhibit 1 disable RAM 


BUS 

CONTROLS 
AND 
ADDRESS 


25 
27 
29 
31 
33 


BHEN/ 
CBRQ/ 
CCLK/ 
INTA/ 


Reserved 

Byte High Enable 

Common Bus Request 

Constant Clk 

Intr Acknowledge 


26 
28 
30 
32 
34 


INH2/ 
AD10/ 
AD11/ 
AD12/ 
AD13/ 


Inhibit 2 disable PROM or ROM 

Address 
Bus 


INTERRUPTS 


35 
37 
39 
41 


INT6/ 
INT4/ 
INT2/ 
INTO/ 


Parallel 

Interrupt 

Requests 


36 
38 
40 
42 


INT7/ 
INT5/ 
INT3/ 
INT1/ 


Parallel 

Interrupt 

Requests 


ADDRESS 


43 
45 
47 
49 
51 
53 
55 
57 


ADRE/ 
ADRC/ 
ADRA/ 
ADR8/ 
ADR6/ 
ADR4/ 
ADR2/ 
ADRO/ 


Address 
Bus 


44 
46 
48 
50 
52 
54 
56 
58 


ADRF/ 
ADRD/ 
ADRB/ 
ADR9/ 
ADR7/ 
ADR5/ 
ADR3/ 
ADR1/ 


Address 
Bus 


DATA 


59 
61 
63 
65 
67 
69 
71 
73 


DATE/ 
DATC/ 
DATA/ 
DAT8/ 
DAT6/ 
DAT4/ 
DAT2/ 
DATO/ 


Data 
Bus 


60 
62 
64 
66 
68 
70 
72 
74 


DATE/ 
DATD/ 
DATB/ 
DAT9/ 
DAT7/ 
DAT5/ 
DAT3/ 
DAT1/ 


Data 
Bus 


POWER 
SUPPLIES 


75 
77 
79 
81 
83 
85 


GND 

-12V 
+ 5V 
+ 5V 
GND 


Signal GND 
Reserved 
-12Vdc 
+ 5Vdc 
+ 5Vdc 
Signal GND 


76 
78 
80 
82 
84 
86 


GND 

-12V 
+ 5V 
+ 5V 
GND 


Signal GND 
Reserved 
-12Vdc 
+ 5Vdc 
+ 5Vdc 
Signal GND 


All Mnemonics © Intel Corporation 1978 
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APPENDIX A (Continued) 
P2 CONNECTOR PIN ASSIGNMENT OF OPTIONAL BUS SIGNALS 



PIN 


(COMPONENTSIDE) 


PIN 


(CIRCUIT SIDE) 


MNEMONIC 


DESCRIPTION 


MNEMONIC 


DESCRIPTION 


1 


GND 


Signal GND 


2 


GND 


Signal GND 


3 


5 VB 


+ 5V Battery 


4 


5VB 


+ 5V Battery 


5 




Reserved 


6 


VCCPP 


+ 5V Pulsed Power 


7 


-5VB 


-5V Battery 


8 


-5 VB 


-5V Battery 


9 




Reserved 


10 


Reserved 




11 


12 VB 


+ 12V Battery 


12 


12 VB 


+ 12V Battery 


13 


PFSR/ 


Power Fail Sense Reset 


14 


Reserved 




15 


-12 VB 


-12V Battery 


16 


-12 VB 


-12V Battery 


17 


PFSN/ 


Power Fail Sense 


18 


ACLO 


AC Low 


19 


PFIN/ 


Power Fail Interrupt 


20 


MPRO/ 


Memory Protect 


21 


GND 


Signal GND 


22 


GND 


Signal GND 


23 


+ 15V 


+ 15V 


24 


+ 15V 


+ 15V 


25 


-15V 


-15V 


26 


-15V 


-15V 


27 


PARI/ 


Parity 1 


28 


HALT/ 


Bus Master HALT 


29 


PAR2/ 


Parity 2 


30 


WAIT/ 


Bus Master WAIT STATE 


31 


\ 




32 


ALE 


Bus Master ALE 


33 


\ 




34 


Reserved 




35 


1 




36 


Reserved 




37 


1 




38 


AUX RESET/ 


Reset switch 


39 


1 




40 


\ 




40 


V 




42 


1 




43 


> Reserved 




44 


I 




45 






46 


/ 




47 






48 


1 




49 






50 


> Reserved 




51 






52 


1 




53 






54 


1 




55 






56 


1 




57 






58 


1 




59 


/ 




60 


' 




Notes: 








1 . PFIN, on slave modules, if possible, should have the o 


Dtion of cor 


meeting to INTO/ on 


PI. 


2. All undefined pins are reserved for future use. 








All Mnemonics © Intel Corporation 1978 
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APPENDIX B 
BUS TIMING SPECIFICATIONS SUMMARY 



Parameter 


Description 


Minimum 


l^axlmum 


Units 


tBCY 


Bus Clock Period 


100 


D.C. 


ns 


tBW 


Bus Clock Width 


0.35 tBCY 


0.65 tBCY 




tSKEW 


BCLK/skew 




3 


ns 


tPD 


Standard Bus 
Propagation Delay 




3 




tAS 


Address Set-Up Time 
(at Slave Board) 


50 




ns 


tDS 


Write Data Set 
UpTime 


50 




ns 


tAH 


Address Hold Time 


50 




ns 


tDHW 


Write Data Hold Time 


50 




ns 


tDXL 


Read Data Set 
UpTimeToXACK 







ns 


tDHR 


Read Data Hold Time 





65 


ns 


tXAH 


Acknowledge Hold 
Time 





65 


ns 


tXACK 


Acknowledge Time 





tTOUT 


ns 


tCMD 


Command Pulse 
Width 


100 


tTOUT 


ns 


t|D 


Inhibit Delay 





100 

(Recommend < 100 ns) 


ns 


tXACKA 


Acknowledge Time of 
of an Inhibited Slave 


t,AD + 50ns 


tTOUT 




tXACKB 


Acknowledge Time of 
an Inhibiting Slave 


1.5 


tTOUT 


MS 


t|AD 


Acknowledge Disable 
from Inhibit (An 
internal parameter on 
an inhibited slave; 
used to determine 
tXACKAMin.) 





100 
(arbitrary) 


ns 


tAIZ 


Address to Inhibits 
High delay 




100 


ns 


tiNTA 


INTA/ Width 


250 




ns 


tCSEP 


Command Separation 


100 




ns 
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APPENDIX B (Continued) 
BUS TIMING SPECIFICATIONS SUMMARY 



Parameter 


Description 


Minimum 


Maximum 


Units 


tBREQL 


iBCLK/toBREQ/ 
Low Delay 





35 


ns 


tBREQH 


IBCLK/toBREQ/ 
High Delay 





35 


ns 


tBPRNS 


BPRN/tolBCLK/ 
Setup Time 


22 




ns 


tBUSY 


BUSY/ delay 
fromiBCLK/ 





70 


ns 


tBUSYS 


BUSY/tolBCLK/ 
Setup Time 


25 




ns 


tBPRO 


iBCLK/toBPRO/ 
(CLK to Priority Out) 





40 


ns 


tBPRNO 


BPRN/toBPRO/ 
(Priority In to Out) 





30 


ns 


tCBRO 


iBCLK/toCBRQ/ 
(CLKto Common 
Bus Request) 





60 


ns 


tCBRQS 


CBRQ/tolBCLK/ 
Setup Time 


35 




ns 


tCPM 


Central Priority 
Module Resolution 
Delay (Parallel 
Priority) 





tBCY-tBREQ 
-2tpD 
-tBPRNS 
-tSKEW 




tCCY 


C-clock Period 


100 


110 


ns 


tew 


C-clock Width 


0.35 tcCY 


0.65 tcCY 


ns 


tiNIT 


INIT/Width 


5 




ms 


tiNITS 


INIT/toMPRO/ 
Setup Time 


100 




ns 


tPBD 


Power Backup 
Logic Delay 





200 


ns 


tPFINW 


PFIN/ Width 


2.5 




ms 


tMPRO 


MPRO/ Delay 


2.0 


2.5 


ms 


tACLOW 


ACLO/ Width 


3.0 




ms 


tPFSRW 


PFSR/ Width 


100 




ns 


tTOUT 


Timeout Delay 


5 


00 


ms 


tDCH 


D.C.Power Supply 
Hold from ALCO/ 


3.0 




ms 


tDCS 


D.C. Power Supply 
Setup to ACLO/ 


5 




ms 
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APPENDIX C 
BUS DRIVERS, RECEIVERS, AND TERMINATIONS 



Driver 1,3 


Receiver 2,3 


Termination | 


Bus Signals 


Location 


Type 


"OL 
Min^a 


Iqh 

Mln^a 


Co 

Maxpf 


Location 


l|L 
Maxma 


>IH 
Wax^a 


C| 
Maxpf 


Location 


Type 


R Units 


DATO/-DATF/ 
(16 lines) 


Masters 
and Slaves 


TRI 


16 


-2000 


300 


Masters 
and Slaves 


-0.8 


125 


18 


1 place 


Pullup 


2.2 KQ 


ADRO/-ADRB/, 


Masters 


TRI 


16 


-2000 


300 


Slaves 


-0.8 


125 


18 


1 place 


Pullup 


2.2 KQ 


BHEN/ 
(21 lines) 


























MRDC/.MWTC/ 


Masters 


TRI 


32 


-2000 


300 


Slaves 
(Memory; 
memory- 
mapped I/O) 


-2 


125 


18 


1 place 


Pullup 


1 KQ 


IORC/,IOWC/ 


Masters 


TRI 


32 


-2000 


300 


Slaves 
(I/O) 


-2 


125 


18 


1 place 


Pullup 


1 KQ 


XACK/ 


Slaves 


TRI 


32 


-2000 


300 


Masters 


-2 


125 


18 


1 place 


Pullup 


510 Q 


INH1/,INH2/ 


Inhibiting 
Slaves 


OC 


16 


' 


300 


Inhibited 
Slaves 

(RAM, PROM, 
ROM, Memory- 
Mapped I/O) 


-2 


50 


18 


1 place 


Pullup 


1 KQ 


BCLK/ 


1 place 
(Master us) 


TTL 


48 


-3000 


300 


Master 


-2 


125 


18 


Mother- 
board 


To-f-SV 
ToGND 


220 Q 

330 Q 


BREQ/ 


Each 
Master 


TTL 


5 


-400 


60 


Central 
Priority 
Module 


2 


50 


18 


Central 
Priority 
Module 
(notreq) 


Pullup 


1 KQ 


BPRO/ 


Each 
Master 


TTL 


5 


-400 


60 


Next Master 
in Serial 
Priority 
Chain at 
its BPRN/ 


-1.6 


50 


18 


(notreq) 






BPRN/ 


Parallel: 

Central 

Priority 

Module 

SeriakPrev 

Masters 

BPRO/ 


TTL 


5 


-400 


300 


Master 


-2 


50 




(notreq) 






BUSY/, CBRQ 


All Masters 


O.C. 


32 


- 


300 


All Masters 


-2 


50 


18 


1 place 


Pullup 


1 KQ 


INIT/ 


Master, 


O.C. 


32 


- 


300 


All 


-2 


50 


18 


1 place 


Pullup 


2.2 KQ 


CCLK/ 


1 place 


TTL 


48 


-3000 


300 


Any 


-2 


125 


18 


Mother- 
board 


T0+5V 
ToGND 


220 Q 
330 Q 


INTA/ 


Masters 


TRI 


32 


-2000 


300 


Slaves 
(Interrupting 
I/O) 


-2 


125 


18 


1 place 


Pullup 


1 KQ 


INT0/-INT7/ 
(8 lines) 


Slaves 


O.C. 


16 


- 


300 


Masters 


-1.6 


40 


18 


1 place 


Pullup 


1 KQ 


PFSR/ 


User's Fron 
Panel? 


TTL 


16 


-400 


300 


Slaves, 
Masters 


-1.6 


40 


18 


1 place 


Pullup 


1 KQ 


PFSN/ 


Power Back 
Up Unit 


TTL 


16 


-400 


300 


Masters 


-1.6 


40 


16 


1 place 


Pullup 


1 KQ 


ACLO 


Power 
Supply 


O.C. 


16 


-400 


300 


Slaves, 
Masters 


-1.6 


40 


18 


1 place 


Pullup 


1 KQ 


PFIN/ 


Power Back- 
up Unit 


O.C. 


16 


-400 


300 


Masters 


-1.6 


40 


18 


1 place 


Pullup 


1 KQ 


MPRO/ 


Power Back- 
up Unit 


TTL 


16 


-400 


300 


Slaves 
Masters 


-1.6 


40 


18 


1 place 


Pullup 


1 KQ 
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APPENDIX C (Continued) 
BUS DRIVERS, RECEIVERS, AND TERMINATIONS 



Driver 1,3 


Receiver 2,3 


Termination { 


Bus Signals 


Location 


Type 


iQL 'OH Co 
Minma Min^a Maxpf 


Location 


IjL "IH C| 
Maxma Max^a Maxpf 


Location 


Type 


R Units 


Aux Reset/ 


User's 

Front 

Panel? 


Switch 
toGND 




Masters 


-2 50 18 


None 






Notes: 

1. Driver Requirements 

10H = High Output Current Drive 
Iql = Low Output Current Drive 
Co = Capacitance Drive Capability 
TRI = 3-State Drive 
O.C. = Open Collector Driver 
TTL = Totem-pole Driver 

2. Receiver Requirements 

l|H = High Input Current Load 
l|L = Low Input Current Load 
Ci = Capacitive Load 

3. TTL low state must be > -0.5v but ^0.8v at the receivers 
TTL high state must be^ 2.0v but < 5.5v at the receivers 

4. For the iSBC 80/10 and the iSBC 80/1 OA use only a IK pull-up resistor to +5v for BCLK/ and CCLK/ termination. 
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APPENDIX D 
BUS POWER SPECIFICATIONS 





Standard (PI) 


Optional (P2) 






Analog 


Power 


Battery Power Backup 




Ground +5 +12 


-12 


+ 15 


-15 


+ 5 +12 


-12 


-5 


Mnemonic 


GND +5V +12V 


-12V 


+ 15V 


-15V 


+ 5B +12B 


-12B 


-5B 


Bus Pins 


PI + 1,2, PI +3,4, PI +7,8 
11,12, 5,6,81, 
75,76 82,83, 
85,86 84 


PI + 79, 
80 


P2 + 23, 
24 


P2 + 25, 
26 


P2 + 3,4, P2+11, 
5,6 12 


P2+15, 
16 


P2-7,8 


Nominal Output 


Ref. +5.0V + 12.0V 


-12.0V 


+ 15.0V 


-15.0V 


+ 5.0V + 12.0V 


-12.0V 


-5.0V 


Tolerance from 
















Nominar 


Ref. ±5% ±5% 


±5% 


±3% 


±3% 


±5% ±5% 


±5% 


±5% 


Ripple 
(Pk-Pk)^ 


Ref. 50 mV 50 mV 


50 mV 


10 mV 


10 mV 


50 mV 50 mV 


50 mV 


50 mV 


Transient 
















Response 
Time^' 


500 fis 500/iS 


500 /iS 


100 ^s 


100 ^s 


500 pls 500 ns 


500 /.s 


500 /iS 


Transient 
















Deviation' 


±10% ±10% 


±10% 


±10% 


±10% 


±10% ±10% 


±10% 


±10% 


NOTES: 










1. Tolerance is worst case, including initial voltage setting line and load effects of 
state influences. 


power source, temperature drift, and any additional steady 


2. As measured over any bandwidth not to exceed to 500 kHz. 








3. As measured from thie start of a load change to the t 


me an output recovers within ±0.1% of final voltage. 






4. Measured as the peak deviation from the initial voltage. 
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APPENDIX E 
MECHANICAL SPECIFICATIONS 




COMPONENT SIDE 



[> 



> 



> 



IflT 



TBI 



■n\o.55 

-J —0. 



5.950 
tO.005 



TT 




' CHAMFER ALL 
CONNECTOR EDGES 
0.040 X 45° 



^ 



BOARD THICKNESS: 0.062 

MULTIBUS CONNECTOR; 86-PIN, 0.156 SPACING 
CDC VFB01E43D00A1 
VIKING 2VH43/1ANE5 

AUXILIARY CONNECTOR: 60PIN, 0.100 SPACING 
CDC VPB01B30D00A1 
Tl H311130 
AMP PE5-14569 



^ 



EJECTOR TYPE: SCANBE #S203 

BUS DRIVERS AND RECEIVERS SHOULD BE LOCATED AS CLOSE AS POSSIBLE TO 
THEIR RESPECTIVE MULTIBUS PIN CONNECTIONS 

BOARD SPACING: 0.6 

COMPONENT HEIGHT: 0.4 

CLEARANCE ON CONDUCTOR NEAR EDGES: 0.050 
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APPENDIX F 

MULTIBUS™ SLAVE DESIGN EXAMPLE SCHEMATIC 

8/16-BIT VERSION 
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MULTIBUS™ SLAVE DESIGN EXAMPLE SCHEMATIC 8/16-BIT VERSION 



APPENDIX G 

MULTIBUS™ SLAVE DESIGN EXAMPLE SCHEMATIC 

8-BIT VERSION 
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I. INTRODUCTION 

The iSBC 957 Intellec— iSBC 86/12 Interface and 
Execution Package contains the hardware and soft- 
ware required to interface an iSBC 86/12 Single 
Board Computer with an Intellec Microcomputer 
Development System. The iSBC 957 package gives 
the 8086 user the capability to develop software on 
an Intellec System and then debug this software on 
an iSBC 86/12 board using a program download 
capability and an interactive system monitor. The 
8086 user has all the capabilities of the Intellec sys- 
tem at his disposal and has the powerful iSBC 
86/12 system monitor commands to use for 
debugging 8086 programs. 

The iSBC 86/12 board is an Intel 8086 based proc- 
essor board which, in addition to the processor, 
contains 32K bytes of dual port RAM, sockets for 
up to 16K bytes of ROM/EPROM, a serial I/O 
port, 24 parallel I/O lines, 2 programmable 
counters, 9 levels of vectored priority interrupts, 
and an interface to the MULTIBUS^'^ system bus. 
The iSBC 957 package consists of monitor EPROMs 
for the iSBC 86/12 board. Loader software for the 
Intellec system, four (4) cable assemblies, assorted 
line drivers and terminators, and signal adapters. 
The iSBC 957 package provides the capability of 
downloading and uploading program and data 
blocks between an iSBC 86/12 board and an Intellec 
system. In addition, monitor commands and 
displays may be input and viewed from the Intellec 
system console. The iSBC 957 package, when used 
with the iSBC 86/12 board and an Intellec Micro- 
computer Development System, provides the user 
with the capability to edit, compile or assemble, 
link, locate, download, and interactively debug 
programs for the 8086 processor. The iSBC 957 
package and the iSBC 86/12 board form an ex- 
cellent '^execution vehicle" for users developing 
software for the 8086 processor regardless of 
whether the users are 8086 component users or 
iSBC 86/12 board users. Using the iSBC 957 pack- 
age 8086 programs may be debugged at the full 5 
MHz speed of the processor. The recommended 
hardware for the execution vehicle is an iSBC 660 
system chassis with an 8 card slot backplane and 
power supply, an iSBC 032 32K byte RAM memory 
board, the iSBC 957 package, and the iSBC 86/12 
board. 

This application note will describe how the iSBC 
957 package may be used to develop and debug 
8086 programs. First a description of the iSBC 
86/12 board will be presented. Readers familiar 



with the iSBC 86/12 board may want to skip this 
section. Next follows a detailed description of the 
iSBC 957 package and the iSBC 86/12 system 
monitor commands. A program example of a 
matrix multiplication routine will then be presented. 
This example will contain both assembly language 
and PL/M-86 procedures. The steps required to 
compile, assemble, link, locate and debug the 
program code will be explained in detail. A typical 
debugging session using the iSBC 86/12 system 
monitor will be presented. 



II. THE iSBC™ 86/12 SINGLE BOARD 
COMPUTER 

The iSBC 86/12 Single Board Computer, which is 
a member of Intel's complete line of iSBC 80/86 
computer products, is a complete computer system 
on a single printed-circuit assembly. The iSBC 86/ 
12 board includes a 16-bit central processing unit 
(CPU), 32K bytes of dynamic RAM, a serial com- 
munications interface, three programmable parallel 
I/O ports, programmable timers, priority interrupt 
control, MULTIBUS control logic, and bus expan- 
sion drivers for interface with other MULTIBUS- 
compatible expansion boards. Also included is dual 
port control logic to allow the iSBC 86/12 board 
to act as a slave RAM device to other MULTIBUS 
masters in the system. Provision is made for user 
installation of up to 16K bytes of read only mem- 
ory. Figure 1 contains a block diagram of the iSBC 
86/12 board and in Appendix A is a simplified 
logic diagram of the iSBC 86/12 board. 

Central Processing Unit 

The central processor for the iSBC 86/12 board is 
Intel's 8086, a powerful 16-bit H-MOS device. The 
225 sq. mil chip contains 29,000 transistors and has 
a clock rate of 5MHz. The architecture includes 
four (4) 16-bit byte addressable data registers, two 
(2) 16-bit memory base pointer registers and two (2) 
16-bit index registers, all accessed by a total of 24 
operand addressing modes for complex data han- 
dling and very flexible memory addressing. 

Instruction Set — The 8086 instruction repertoire 
includes variable length instruction format (in- 
cluding double operand instructions), 8-bit and 16- 
bit signed and unsigned arithmetic operators for 
binary, BCD and unpacked ASCII data, and iter- 
ative word and byte string manipulation functions. 
The instruction set of the 8086 is a functional 
superset of the 8080A/8085A family and with 
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INTERFACE 



Figure 1. iSBC™ 86/12 Single Board Computer Block Diagram 



available software tools, programs written for the 
8080A/8085A can be easily converted and run on 
the 8086 processor. 

Architectural Features — A 6-byte instruction queue 
provides pre-fetching of sequential instructions and 
can reduce the 1.2 m sec minimum instruction cycle 
to 400 nsec by having the instruction already in the 
queue. 

The stack oriented architecture facilitates nested 
sub-routines and co-routines, reentrant code and 
powerful interrupt handling. The memory expan- 
sion capabilities offer a 1 megabyte addressing 
range. The dynamic relocation scheme allows ease 
in segmentation of pure procedure and data for 
efficient memory utilization. Four segment registers 
(code, stack, data, extra) contain program loaded 
offset values which are used to map 16-bit addresses 
to 20-bit addresses. Each register maps 64K-bytes at 
a time and activation of a specific register is con- 
trolled explicitly by program control and is also 
selected implicitly by specific functions and 
instructions. 



Bus Structure 

The iSBC 86/12 board has an internal bus for 
communicating with on-board memory and I/O 
options, a system bus (the MULTIBUS) for refer- 
encing additional memory and I/O options, and 
the dual-port bus which allows access to RAM 
from the on-board CPU and the MULTIBUS Sys- 
tem Bus. Local (on-board) accesses do not require 
MULTIBUS communication, making the system 
bus available for use by other MULTIBUS masters 
(i.e. DMA devices and other single board com- 
puters transferring to additional system memory). 
This feature allows true parallel processing in a 
multiprocessor environment. In addition, the MUL- 
TIBUS interface can be used for system expansion 
through the use of other 8- and 16-bit iSBC com- 
puters, memory and I/O expansion boards. 

RAM Capabilities 

The iSBC 86/12 board contains 32K-bytes of 
dynamic read /write memory. Power for the on- 
board RAM and refresh circuitry may be option- 
ally provided on an auxiliary power bus, and 
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memory protect logic is included for RAM battery 
backup requirements. The iSBC 86/12 board con- 
tains a dual port controller which allows access to 
the on-board RAM from the iSBC 86/12's CPU 
and from any other MULTIBUS master via the 
system bus. The dual port controller allows 8- and 
16-bit accesses from the MULTIBUS System Bus 
and the on-board CPU transfers data to RAM over 
a 16-bit data path. Priorities have been established 
such that memory refresh is guaranteed by the on- 
board refresh logic and that the on-board CPU has 
priority over MULTIBUS requests for access to 
RAM. The dual-port controller includes independent 
addressing logic for RAM access from the on-board 
CPU and from the MULTIBUS system bus. The 
on-board CPU will always access RAM starting 
at location OOOOOh- Address jumpers allow on- 
board RAM to be located starting on any 8K-byte 
boundary within a 1 megabyte address range for 
accesses from the MULTIBUS system bus. In con- 
junction with this feature, the iSBC 86/12 board 
has the ability to protect on-board memory from 
MULTIBUS access to any contiguous 8K-byte 
segments. These features allow multi -processor 
systems to establish local memory for each proces- 
sor and shared system (MULTIBUS) memory con- 
figurations where the total system memory size 
(including local on-board memory) can exceed 1 
megabyte without addressing conflicts. 

EPROM/ROM Capabilities 

Four sockets are provided for up to 16K-bytes of 
non-volatile read only memory on the iSBC 86/12 
board. Configuration jumpers allow read only 
memory to be installed in 2K, 4K, or 8K increments. 

On-board ROM is accessed via 16 bit data paths. 
System memory size is easily expanded by the 
addition of MULTIBUS compatible memory boards 
available in the iSBC 80/86 family. 

Parallel I/O Interface 

The iSBC 86/12 board contains 24 programmable 
parallel I/O lines implemented using the Intel 
825 5 A Programmable Peripheral Interface. The 
system software is used to configure the I/O lines 
in any combination of unidirectional input /output 
and bidirectional ports. 

Therefore, the I/O interface may be customized to 
meet specific peripheral requirements. In order to 
take full advantage of the large number of possible 
I/O configurations, sockets are provided for inter- 
changeable I/O line drivers and terminators. 
Hence, the flexibility of the I/O interface is further 



enhanced by the capability of selecting the appro- 
priate combination of optional line drivers and 
terminators to provide the required sink current, 
polarity, and drive /termination characteristics for 
each appHcation. The 24 programmable I/O lines 
and signal ground lines are brought out to a 50-pin 
edge connector that mates with flat, woven, or 
round cable. 

Serial I/O 

A programmable communications interface using 
the Intel 8251 A Universal Synchronous /Asyn- 
chronous Receiver /Transmitter (US ART) is con- 
tained on the iSBC 86/12 board. A software 
selectable baud rate generator provides the USART 
with all common communication frequencies. The 
USART can be programmed by the system soft- 
ware to select the desired asynchronous or syn- 
chronous serial data transmission technique (in- 
cluding IBM Bi-Sync). The mode of operation (i.e., 
synchronous or asynchronous), data format, con- 
trol character format, parity, and baud rate are all 
under program control. The 8251 A provides full 
duplex, double buffered transmit and receive capa- 
bility. Parity, overrun, and framing error detection 
are all incorporated in the USART. The RS232C 
compatible interface on each board, in conjunction 
with the USART, provides a direct interface to 
RS232C compatible terminals, cassettes, and asyn- 
chronous and synchronous modems. The RS232C 
command lines, serial data lines, and signal ground 
line are brought out to a 26 pin edge connector that 
mates with RS232C compatible flat or round cable. 
The iSBC 530 teletypewriter adapter provides an 
optically isolated interface for those systems re- 
quiring a 20 mA current loop. The iSBC 530 
adapter may be used to interface the iSBC 86/12 
board to teletypewriters or other 20 mA current 
loop equipment. 

Programmable Timers 

The iSBC 86/12 board provides three independent, 
fully programmable 16-bit interval timers /event 
counters utiUzing the Intel 8253 Programmable In- 
terval Timer. Each counter is capable of operating 
in either BCD or binary modes. Two of these 
timers /counters are available to the systems de- 
signer to generate accurate time intervals under 
software control. Routing for the outputs and gate/ 
trigger inputs of two of these counters is jumper 
selectable. The outputs may be independently 
routed to the 8259A Programmable Interrupt Con- 
troller and to the I/O line drivers associated with 
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the 8255A Programmable Peripheral Interface, or 
may be routed as inputs to the 825 5 A chip. The 
gate /trigger inputs may be routed to I/O termin- 
ators associated with the 8255A or as output con- 
nections from the 8255A. The third interval timer 
in the 8253 provides the programmable baud rate 
generator for the iSBC 86/12 RS232C US ART 
serial port. In utilizing the iSBC 86/12, the systems 
designer simply configures, via software, each timer 
independently to meet system requirements. When- 
ever a given time delay or count is needed, soft- 
ware commands to the programmable timers /event 
counters select the desired function. 

The contents of each counter may be read at any 
time during system operation with simple read 
operations for event counting applications, and 
special commands are included so that the contents 
can be ready *'on the fly". 

MULTIBUS^'^ and Multimaster Capabilities 

The MULTIBUS system bus features asynchronous 
data transfers for the accommodation of devices 
with various transfer rates while maintaining maxi- 
mum throughput. Twenty address lines and sixteen 
separate data lines eliminate the need for address/ 
data multiplexing /demultiplexing logic used in 
other systems, and allow for data transfer rates up 
to 5 megawords/sec. A failsafe timer is included in 
the iSBC 86/12 board which can be used to gener- 
ate an interrupt if an addressed device does not 
respond within 6 msec. 

Multimaster Capabilities — The iSBC 86/12 board 
is a full computer on a single board with resources 
capable of supporting a great variety of OEM sys- 
tem requirements. For those applications requiring 
additional processing capacity and the benefits of 
multiprocessing (i.e., several CPUs and/or con- 
trollers logically sharing system tasks through 
communication over the system bus), the iSBC 86/ 
12 board provides full MULTIBUS arbitration 
control logic. This control logic allows up to three 
iSBC 86/12 boards or other bus masters, including 
iSBC 80 family MULTIBUS compatible 8-bit single 
board computers, to share the system bus in serial 
(daisy chain) priority fashion, and up to 16 masters 
to share the MULTIBUS with the addition of an 
external priority network. The MULTIBUS arbitra- 
tion logic operates synchronously with a MULTI- 
BUS clock provided by the iSBC 86/12 board or 
optionally provided directly from the MULTIBUS 
System Bus) while data is transferred via a hand- 
shake between the master and slave modules. This 



allows different speed controllers to share resources 
on the same bus, and transfers via the bus proceed 
asynchronously. Thus, transfer speed is dependent 
on transmitting and receiving devices only. This 
design prevents slow master modules from being 
handicapped in their attempts to gain control of the 
bus, but does not restrict the speed at which faster 
modules can transfer data via the same bus. The 
most obvious applications for the master-slave 
capabilities of the bus are multiprocessor configur- 
ations, high speed direct memory access (DMA) 
operations, and high speed peripheral control, but 
are by no means limited to these three. 

Interrupt Capability 

The iSBC 86/12 board provides 9 vectored interrupt 
levels. The highest level is the NMI (Non-Maskable 
Interrupt) line which is directly tied to the 8086 
CPU. This interrupt cannot be inhibited by soft- 
ware and is typically used for signalling catastrophic 
events (e.g., power failure). 

The Intel 8259A Programmable Interrupt Con- 
troller (PIC) provides vectoring for the next eight 
interrupt levels. 

The PIC accepts interrupt requests from the pro- 
grammable parallel and serial I/O interfaces, the 
programmable timers, the system bus, or directly 
from peripheral equipment. The PIC then deter- 
mines which of the incoming requests is of the 
highest priority, determines whether this request is 
of higher priority than the level currently being 
serviced, and, if appropriate, issues an interrupt to 
the CPU. Any combination of interrupt levels may 
be masked, via software, by storing a single byte 
in the interrupt mask register of the PIC. The PIC 
generates a unique memory address for each in- 
terrupt level. These addresses contain unique 
instruction pointers and code segment offset values 
(for expanded memory operation) for each interrupt 
level. In systems requiring additional interrupt 
levels, slave 8259A PIC's may be interfaced via the 
MULTIBUS system bus, to generate additional 
vector addresses, yielding a total of 65 unique 
interrupt levels. 

Interrupt Request Generation — Interrupt requests 
may originate from 16 sources. Two jumper select- 
able interrupt requests can be automatically gener- 
ated by the programmable peripheral interface. 

Two jumper selectable interrupt requests can be 
automatically generated by the USART when a 
character is ready to be transferred to the CPU or a 
character is ready to be transmitted. 
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A jumper selectable request can also be generated 
by each of the programmable timers. Eight addi- 
tional interrupt request lines are available to the 
user for direct interface to user designated peripher- 
al devices via the system bus, and two interrupt 
request lines may be jumper routed directly from 
peripherals via the parallel I/O driver /terminator 
section. 

Power-Fail Control 

Control logic is also included to accept a power-fail 
interrupt in conjunction with the AC-low signal 
from the iSBC 635 Power Supply or equivalent. 

Expansion Capabilities 

Memory and I/O capacity may be expanded and 
additional functions added using Intel MULTIBUS 
compatible expansion boards. High speed integer 
and floating point arithmetic capabilities may be 
added by using the iSBC 310 high speed mathe- 
matics unit. Memory may be expanded to 1 mega- 
byte by adding user specified combinations of 
RAM boards, EPROM boards, or combination 
boards. Input /output capacity may be increased by 
adding digital I/O and analog I/O expansion 
boards. Mass storage capability may be achieved 
by adding single or double density diskette con- 
trollers. Modular expandable backplanes and card- 
cages are available to support multiboard systems. 

III. THE iSBC™ 957 PACKAGE 

The iSBC 957 Intellec— iSBC 86/12 Interface and 
Execution Package extends the software develop- 
ment capabilities of the Intellec Microcomputer 
Development systems to the Intel 8086 CPU. Pro- 
grams for the 8086 may be written in PL/M-86 
and /or assembly language and compiled or as- 
sembled on the Intellec system. These programs 
may then be downloaded from an Intellec ISIS-II 
disk file to the iSBC 86/12 board for execution and 
debug. The programs will execute at the full 5 MHz 
clock rate of the 8086 CPU with no speed degrada- 
tion caused by the iSBC 957 hardware or software. 
Special communication software allows transparent 
access to the powerful interactive debug commands 
in the iSBC 86/12 monitor from the Intellec con- 
sole terminal. These debug commands include 
single-step instruction execution, execution with 
breakpoints, memory and register displays, memory 
searches, comparison of two memory blocks and 
several other commands. After a debugging session, 
the debugged program code may be uploaded from 
the iSBC 86/12 board to an Intellec ISIS-II disk 
file. 



The iSBC 957 Intellec— iSBC 86/12 Interface and 
Execution Package consists of the following: 

a. Four Intel 2716 EPROMs which contain the sys- 
tem monitor program for the iSBC 86/12 board. 

b. An ISIS-II diskette containing loader software 
for execution in the Intellec which provides for 
communications between the user or an Intellec 
ISIS-II file and the iSBC 86/12 board. Also in- 
cluded on the diskette are a library of routines 
for system console I/O. 

c. Four cable assemblies used for transmitting com- 
mands, code and data between the iSBC 86/12 
board and the Intellec system. 

d. An iSBC 530 adapter assembly which converts 
serial communications signals from current loop 
to RS232C. 

e. Line drivers and terminators used for the iSBC 
86/12 parallel ports. 

f. A small printed circuit board which is plugged 
into an iSBC 86/12 receiver /terminator socket 
and is used when program code is downloaded 
or uploaded using the parallel cable. 

iSBC™— Intellec™ Configurations 

There are two distinct functional configurations for 
the iSBC 957 package; one configuration for the 
Intellec Series II, Models 220 or 230 development 
systems and another for the Intellec 800 series 
development systems. 

Intellec Series II System Configurations 

When used with Intellec Series II Model 220 or 
230 systems, a set of cables are used to connect the 
serial I/O port edge connector on the iSBC 86/12 
board and the SERIAL 1 output port on the Intellec 
system. This configuration is shown in Figure 2. 
How this system functions is explained in the fol- 
lowing paragraphs. 

The SERIAL 1 port on the Intellec Series II Model 
220 or 230 system is an RS232 port which is de- 
signed for use with a data terminal. This port may 
be used on the Intellec system for interfacing to 
RS232 devices such as CRT terminals or printers. 
The serial ports on the iSBC 86/12 board and the 
Intellec systems are connected as shown in the 
Figure 2. The flat ribbon cable connected to the 
iSBC 86/12 board has an edge connector for con- 
necting to the board on one end and a standard 
RS232 connector on the other end. The second 
cable, the RS232 Up /Down Load cable, has an 
RS232 connector on each end. This cable, however, 
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INTELLEC SERIES II 
MODEL 220, 230 




OEM RS232-C 
CABLE 



RS232UP/DOWN LOAD 
CABLE 



Figure 2. Intellec™ Series II Model 220, 230-1860™ 86/12 Configuration 



is not a standard cable with the RS232 signals bussed 
between identically numbered pins on each of the 
connectors. The schematic for the cable is shown in 
Figure 3. Note that the TXD (transmit data) and 
the RXD (receive data) and the RTS (ready to send) 
and the CTS (clear to send) signals have been 
crossed. This is done because both the Intellec system 
and the iSBC 86/12 board are configured to act as 
data sets which are communicating with data 
terminals. Swapping these signals permits the units 
to communicate directly with no modifications to 
the Intellec or iSBC 86/12 systems themselves. 



FGD (FRAME GROUND) 

TXD (TRANSMIT DATA) 

RXD (RECEIVE DATA) 

RTS (READY TO SEND) 

CTS (CLEAR TO SEND) 

SGD (SIGNAL GROUND) 



Figure 3. IntellecTM-iSBCTM 86/12 RS232 
UP /DOWN LOAD Cable 



The software in the Intellec system accepts characters 
output from the iSBC 86/12 board through the 
Intellec SERIAL 1 port. The software then outputs 
these characters on the CRT monitor built into the 
Intellec Series II Model 220 or 230. In a similar 
fashion, characters input from the Intellec key- 




board are passed down the serial link to the iSBC 
86/12 monitor program. The integrated CRT 
monitor and keyboard on the Intellec system then 
becomes the ^Virtual terminal" of the iSBC 86/12 
monitor program. If this were the only function of 
the iSBC 957 package, there would be no real 
benefit to the user. However, when the "virtual 
terminal" capability is combined with the capa- 
bility to download and upload program code and 
data files between the Intellec ISIS-II file system 
and the iSBC 86/12 board, a very powerful soft- 
ware development tool is realized. The software in 
the Intellec system must examine the commands 
which are input from the keyboard and in the case 
of the LOAD and TRANSFER commands (see 
later sections for details on monitor commands), 
the software must open and read or write ISIS-II 
disk files. 

Transfer rates using Intellec Series II Model 220 or 
230 system are 9600 baud when transferring hexa- 
decimal object files to or from a disk file and 600 
baud when transferring commands between the 
iSBC 86/12 board and the CRT monitor and key- 
board. With a 9600 baud transfer rate, it is pos- 
sible to load 64K bytes of memory in about four 
minutes. 



Intellec 800 System Configurations 

The iSBC 957 package may be used with the In- 
tellec 800 system in four different configurations. 
These four configurations are determined by two 
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variables. The first variable is whether the iSBC 
86/12 board is connected to the Intellec 800 TTY 
port or to the Intellec 800 CRT port. The second 
variable is whether or not a parallel cable is used 
for uploading and downloading hexadecimal object 
files. Figures 4 A and 4B illustrate the four 
configurations. 

In Figure 4A, the configuration shows the TTY 
port of the Intellec 800 system connected to the 
iSBC 86/12 serial port using two cables and an 
iSBC 530 teletypewriter adapter. The TTY port of 
the Intellec 800 system is designed for using a 
teletypewriter as the Intellec console device. To use 
this port for communication with the iSBC 86/12 
board, the current loop TTY signal must be con- 
verted to an RS232 compatible voltage signal. This 
function is performed by the iSBC 530 adapter. 



The cable which connects the Intellec 800 system to 
the iSBC 530 adapter performs a function similar 
to the RS232 Up /Down Load cable described 
above. A schematic for this cable and all other 
components of the iSBC 957 package are included 
with the delivered product. 

The transfer rate for both commands and data 
when the TTY port is connected to the iSBC 86/12 
board is 110 baud. This means to download even 
moderately sized programs would require large 
amounts of time, several minutes or even hours. 
However, much faster times may be achieved by 
using the parallel ports of the iSBC 86/12 board 
and the Intellec system for downloading program 
files. This parallel port used on the Intellec 800 
system is the output port labeled PROM which is 
normally used with the Universal Prom Pro- 



4A 




OEM RS232-C 
CABLE 



TTY 
PORT 



TTY UP /DOWNLOAD 
CABLE 



SBC 530 
TTY ADAPTER 



4B 




OEM RS232-C 
CABLE 



RS232 UP /DOWNLOAD 
CABLE 



Figure 4A, 4B. IntellecTM 800-iSBCTM 86/12 Configurations 
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grammer. A cable is connected between the In- 
tellec PROM port and the parallel I/O port, Jl of 
the iSBC 86/12 board. Parallel port B of the iSBC 
86/12 board is used for the 8-bit byte transfers 
from the Intellec system to the iSBC 86/12 board, 
port A is used for the byte transfers from the iSBC 
86/12 board to the Intellec system and port C is 
used for controlling the byte transfers. A special 
status adapter piggyback board must be inserted 
into a receiver /terminator socket of the iSBC 86/12 
board. This status adapter circuit is required to 
provide the necessary handshaking signals from the 
iSBC 86/12 parallel ports to the Intellec PROM 
port. 

The transfer rate achieved when downloading and 
uploading hexadecimal object files with the parallel 
cable is approximately 1,000 bytes per second. The 
time required to load 64K bytes of memory is 
approximately IVi minutes. 

Figure 4B shows a configuration with the Intellec 
800 CRT port connected to the serial port of the 
iSBC 86/12 board. The TTY port of the Intellec 
800 system is connected to a teletypewriter or some 
other current loop device to act as a system con- 
sole. The optional parallel load cable is also shown. 
The cables used for this configuration are the same 
as those used with the Intellec Series II Configur- 
ations. Command transfer rates require 110 baud 
because the TTY port of the Intellec 800 system is 
used for communicating with the console device. 
However, hexadecimal object files can be loaded at 
9600 baud since this operation uses only the Intellec 
to iSBC 86/12 RS232 link. 

It is also possible to download files with the parallel 
cable, this mode being somewhat faster than the 
serial download mode {IVi minutes versus four 
minutes for 64K bytes of memory). Table I con- 
tains a summary of the command and memory 
transfer rates for each of the Intellec-iSBC 86/12 
configurations. 

Comparing the Intellec 800 configurations shown in 
Table 1 and in Figures 4A and 4B it should be 
noted: 

1. Using the TTY port (Figure 4A) of the Intellec 
800 system for communications with the iSBC 
86/12 board (essentially) requires installation of 
the parallel cable and jumper modifications for 
downloading and uploading files, and thus, pre- 
vents the use of the parallel ports for other I/O 
functions. 

2. Using the CRT port (Figure 4B) of the Intellec 



800 system for communication with the iSBC 
86/12 board provides for a fast serial download 
capability, thus freeing the parallel ports for 
other uses. However, this configuration requires 
a teletypewriter or a CRT capable of accepting 
a current loop input signal as the Intellec system 
console. 



Table 1 

COMMAND AND MEMORY TRANSFER RATES FOR 

INTELLEC-iSBCTM 86/12 CONFIGURATIONS 





INTELLEC 








SERIES II 220/230 


INTELLEC 800 


INTELLEC 800 




SERIAL PORT 


TTY PORT 


CRT PORT 




TO ISBC 86/12 


TOiSBC86/12 


TO ISbC 86/12 


Effective 








Command Rate 


600 Baud 


110 Baud 


110 Baud* 


Load / Transfer 








Rate 








Serial 


9600 Baud 


110 Baud 


9600 Baud 


Parallel 


N/A 


IK bytes /sec** 


IK bytes /sec** 


Approximate Time 








to load 64K bytes 








of memory 








Serial 


4 minutes 


5 hours 


4 minutes 


Parallel 


N/A 


2.5 minutes 


2.5 minutes 



•The actual baud rate of the Intellec-iSBC 86/12 link is 9600 baud, but the effective 
command rate is determined by the slower Intellec— console serial link. 

* 'Transmission rate over the parallel link is determined by the speed of the two processors 
and is approximately IK bytes per second. 



IV. THE iSBC 957— iSBC 86/12 MONITOR 
PROGRAM 

The iSBC 86/12 monitor program is an EPROM 
resident program which facilitates debugging of 
user written programs. The monitor program used 
in the iSBC 86/12 board with the iSBC 957 pack- 
age is the same monitor program written to inter- 
face the iSBC 86/12 directly to an RS232C data 
terminal. When interfaced directly to a terminal, 
the iSBC 86/12 board functions in a stand-alone 
environment communicating directly with the user 
via the data terminal. A user may use the monitor 
for entering small programs in hexadecimal format, 
executing a program, examining registers and 
memory contents, etc. 

To use the monitor program with an Intellec system, 
the proper cables must be installed and the iSBC 
957 Loader program must be loaded into Intellec 
memory and executed. The Loader program is resi- 
dent on a file named SBC861, and when executed, 
the Loader outputs a sign-on message. Next, the 
iSBC 86/12 monitor program must be started and 
the baud rate of the iSBC 86/12 to Intellec serial 
communications link must be determined. This is 
done by pressing the RESET switch on the chassis 
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Table 2 
MONITOR COMMAND LIST 



COMMAND 



FUNCTION AND SYNTAX 



L Load Hex 
Object File 



T Transfer Hex 
Object File 



Loads hexadecimal object file from Intellec into iSBC 
86/12 memory using serial (S) or parallel (P) mode. 

L <S I P> < filename>[,<bias addr>\<cr> 

Transfers blocks of iSBC 86/12 memory to Intellec as 
a hex object file using serial (S) or parallel (P) mode. 

T[X] |S|p| ,<start addr><end addr>,<filename> 

[,<exec addr>]<cr> 
Exits the loader program and returns to ISIS. 
E<c/-> 



N Single Step 


Executes one user program instruction. 




N[<addr>\,l[<addr>],[*<cr> 


G Go 


Transfers control of the 8086 CPU to the user program 
with up to 2 optional breakpoints. 




GUstart addr>] [,<break 1 addr> 




[,<break2addr>]]<cr> 


S Substitute 
Memory 


Displays/modifies memory locations in byte or word 
format. 




S[V^]<addr>,[{new contents],]* <cr> 


X Examine/Modify 
Register 


Displays/modifies 8086 CPU registers. 
XUregA [[<new contents>],]*<cr> 


D Display Memory 


Displays contents of a memory block in byte or word 
format. 




D[\/\J]<start addr>[<end addr>]<cr> 


M Move 


Moves contents of a memory block. 




M<start addr>,<end addr>< destination addr><cr> 


C Compare 


Compares two memory blocks. 




C<start addr>,<end addr>,<destination addr><cr> 


F Find 


Searches a memory block for a byte or word constant. 




F( W]< start addr>,< end addr>,<data>< cr > 


H Hex Arithmetic 


Performs hexadecimal addition and subtraction. 




H<data 1>,<data 2><cr> 


1 Port Input 


Inputs and displays byte or word data from input 
port. 




\\\N]<portaddr>,[,]*<cr> 


Port Output 


Outputs byte or word data to output port. 




0[\N]<port addr>,<data>[,<data>]*<cr> 



Syntax conventions used in the command structure are as follows: 

[A] indicates that "A" is optional 

[A]* indicates one or more optional iterations of "A" 

<B> indicates that "B" is a variable 
|a|b| indicates "A" or "B" 

<cr> indicates a carriage return is entered 

Numeric arguments can be expressed as a number, the contents of a register, 
or the sum or difference of numbers and register contents. Thus, addresses 
and data can be expressed as follows: 

addr : : = !<expr>:J<expr> 

expr ::= <number>\<register>\<expr> {+ | -} <number>\ 
<expr> {+ I -} < register > 
register ::= AX|BX|CX|DX|SP|BP|SI|DI|CS|DS|SS|ES|IP|FL 
number ::= < digit >|< digit ><number > 

digit ::= 0|1|2|3|4|5|6|7|8|9|A|B|C|D|E|F 

Numeric fields within arguments are entered as hexadecimal numbers. The 
valid range of numerical values is from 0000-FFFF. Larger numbers may be 
entered, but only the last four digits (or two in the case of byte values) are 
significant. Leading zeros may be omitted. 

An address argument consists of a segment value and an offset value separ- 
ated by a colon (:). If a segment value is not specified, the default segment 
value is the CS register value. 



containing the iSBC 86/12 board and typing two 
"U"s on the Intellec console. The ASCII uppercase 
character U has a binary pattern of alternating ones 
and zeros, the iSBC 86/12 monitor uses this pattern 
to determine the baud rate of the serial link. After 
the baud rate has been determined, the monitor 
program outputs a sign-on message to the console. 
An example of loader program execution and 
monitor program initialization is shown below (user 
entered characters are underlined). 

:F1:SBC861 

ISIS-II iSBC 86/12 LOADER, Vx.x 

(user resets iSBC 86/12 board and types two "U"s) 

iSBC 86/12 MONITOR, Vy.y 

The monitor prompts with a period *'." when it is 
ready for a command. The user can then enter a 
command file, which consists of a one- or two- 
character command followed by zero, one, or more 
arguments. The command may be separated from 
the first argument by an optional single space; a 
single comma is required as a delimiter between 
arguments. The command line is terminated by a 
carriage return or a comma depending on the com- 
mand, and no action takes place until the command 
terminator is sensed. The user can cancel a com- 
mand before entering the command terminator by 
pressing any illegal key (e.g., rubout or Control-X). 

Table 2 contains a summary of the loader and 
monitor commands. These commands will not be 
explained in detail; instead, the next section of the 
application note will show examples of using these 
loader and monitor commands. The iSBC 957 
User's Guide referenced at the front of this docu- 
ment does, however, contain a complete description 
of each of the monitor and loader commands. 
Table 3 contains a list of the 8086 hardware registers 
and abbreviations used by the monitor program. 

Table 3 
8086 CPU REGISTERS 



REGISTER NAME 


ABBREVIATION 


Accunnulator 


AX 


Base 


BX 


Count 


cx 


Data 


DX 


Stack Pointer 


SP 


Base Pointer 


BP 


Source Index 


SI 


Destination Index 


Dl 


Code Segment 


CS 


Data Segment 


DS 


Stack Segment 


SS 


Extra Segment 


ES 


Instruction Pointer 


IP 


Flag 


FL 
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EPROM 

(8K bytes) 
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ON-BOARD 
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(32K bytes) 




Figure 5. Memory Map of ISBCtm 86/12 Memory With Monitor Program 



8259A PIC 
VECTORS 



Figure 5 contains a memory map of the iSBC 
86/12 memory with the monitor program. Note 
that the monitor uses the top 8K bytes of memory 
for its program code and the first 384 bytes of 
memory (locations hex to 17F hex) for monitor 
and user stack, data and interrupt vectors. When 
the monitor program is reset, the segment registers, 
the IP and the flags are set to 0; and the SP is set 
to 01C0H allowing 64 bytes for the user's stack. If 
64 bytes is not sufficient for the user's application 
program, the SP should be set to some other value. 
The monitor program sets the single-step, one-byte 
instruction trap and non-maskable interrupt vectors 
to monitor entry points. The monitor also sets the 
8259A Priority Interrupt Controller to fully nested 
mode with level at the highest priority and all 
interrupts unmasked. The eight interrupt vector 
addresses for the 8259A are also set to addresses in 
the monitor. User programs may change the 8259A 
interrupt vectors to interrupt service routine ad- 
dresses within the user programs; it is not necessary 
for users to program the 8259 A chip directly. When 
an interrupt occurs, control passes to either the 
monitor or directly to user code depending on the 
address stored in the vector location. When the 
monitor responds to an interrupt, it acknowledges 
the interrupt and displays the interrupt level, CS 
and IP register values and next instruction byte on 



the system console (e.g., I = 3 @ 100:230F F5). 

When a user requests a breakpoint with a **G" 
command, the monitor inserts the single byte 
instruction trap instructions (INT 3) in the location 
where the breakpoint is requested. It is also possible 
for the user to code an INT 3 instruction in his 
program. When a user coded INT 3 instruction is 
executed, the monitor will be re-entered and a line 
with the format @<CS Value>:<IP Value> <In- 
struction byte > will be displayed (e.g., @1200:3FO2 
F5). 

Included on the diskette with the Loader program 
are two libraries containing I/O routines for the 
console. The library files are named SBCIOS.LIB 
and SBCIOL.LIB; they contain similar routines. 
The routines in SBCIOS.LIB are written to be 
called with intrasegment subroutine calls, a PL/M- 
86 module compiled with the '*smair' control 
generates this type of call. The routines in 
SBCIOL.LIB are written to be called with interseg- 
ment subroutine calls, a PL/M-86 module com- 
piled with either the "medium" or * 'large" control 
generates this type of call. 

The console input output routines, CI and CO, 
contained in the library should be used when per- 
forming character input and output on the console. 
Example PL/M-86 calls to the two routines are: 
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CI: PROCEDURE BYTE EXTERNAL; 

END CI; 
CO: PROCEDURE (X) EXTERNAL; 

DECLARE X BYTE; 

END CO; 



DECLARE INPUTSCHAR, 

OUTPUTSCHAR BYTE; 



INPUTSCHAR = CI; 



CALL CO(OUTPUT$CHAR); 



General Comments on Use of the iSBC 957 Package 

1. If the iSBC 86/12 board is reset any time after 
the initial baud rate search, it is not necessary to 
reload the iSBC 957 Loader program or to 
download the program code a second time to the 
iSBC 86/12 board. It is only necessary to re- 
establish the communications link by typing two 
''U"s for the baud rate search. 

2. The iSBC 86/12 board should not be plugged 
into an available card slot in an Intellec chassis; 
a separate chassis should be used. There are at 
least three reasons for this: 

a. There is only one RESET signal available on 
the Intellec system bus. Thus, each processor 
may not be reset independently. This means 
that the iSBC 86/12 board cannot be reset 
without re-booting the ISIS-II operating sys- 
tem and restarting the iSBC 957 Loader. 

b. The Intellec system uses five of the eight avail- 
able interrupts on the system bus. This severely 
restricts the range of interrupts available to 
the iSBC 86/12 board. Also, the iSBC 86/12 
board cannot turn-off the interrupt lamps on 
the Intellec front panel. 

c. The iSBC 86/12 board may address up to 1 
Megabyte of memory using a 20 bit address. 
Many Intellec systems contain boards which 
generate and decode only the low order 16 
address bits. For example, the iSBC 016 mem- 
ory expansion board and the Intellec 800 



monitor PROMs only decode 16 address bits. 
Memory expansion above 64K bytes in these 
systems is difficult since the boards which de- 
code only 16 bits will force "holes" in the 
address space above 64K. 

3. The iSBC 86/12 board is delivered with two 
inputs to the 8259A Priority Interrupt Controller 
connected. Interrupt request 2 (IR2) is connected 
to the counter output of the 8253 Program- 
mable Interval Timer. IR5 is connected to the 
INT5 /signal of the MULTIBUS System Bus. If 
these interrupts are not desired, the wire wrap 
jumpers making the connections should be re- 
moved from the iSBC 86/12 board. A particular 
problem may exist with the counter connection 
to IR2. If the 8253 counter is not specifically 
initialized with software, a low frequency square 
wave output will exist at counter 0's output. This 
may cause unwanted interrupts when interrupts 
are enabled by user programs. 

4. If the iSBC 86/12 board is used in a system with 
expansion boards, it is important that the MUL- 
TIBUS bus exchange pins be properly jumpered. 
For example, if the iSBC 86/12 board is used 
with an iSBC 032 expansion memory board in a 
system, the BPRN/ MULTIBUS pin for the 
iSBC 86/12 board should be grounded. 

In addition, if any interrupts are used with the 
iSBC 86/12 board the BPRN/ pin must be 
grounded. This is true in both single and mul- 
tiple board systems. 

5. Certain user systems require more than one single 
board computer in the system for performing the 
functions required by the application. The MUL- 
TIBUS System Bus has been specifically designed 
to permit multiple CPU boards to communicate 
and to share system resources. However, de- 
bugging systems with multiple CPUs has always 
posed somewhat of a problem. The iSBC 957 
package provides a solution to this problem. The 
serial cable which connects the iSBC 86/12 
board to the Intellec system may be removed 
after the program has been downloaded to the 
iSBC 86/12 board. A console CRT may then be 
connected directly to the iSBC 86/12 board and 
the monitor program may be used to debug the 
program running on the board. Other iSBC 
86/12 boards may also be downloaded from the 
Intellec system and then switched to their own 
local terminals. An 8-bit processor board, such 
as the iSBC 80/30 board, may also be included 
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in the system and ICE-85™ may be used for 
debugging the iSBC 80/30 program concurrently 
with the iSBC 86/12 programs. Using this 
scheme, it is possible to debug a system which 
has several CPU boards by setting breakpoints 
and using other debugging features on each of 
the individual CPUs. 

V. MATRIX MULTIPLICATION EXAMPLE 

To illustrate how the iSBC 957 package can be used 
to assist in the writing and debugging of 8086 pro- 
grams on the iSBC 86/12 board, an example pro- 
gram of a matrix multiplication will be presented. 
The example chosen has been intentionally kept 
simple and straightforward. The emphasis of this 
section will be to document the steps required to as- 
semble, compile, link, locate and debug software 
using an Intellec system, the iSBC 957 package and 
the iSBC 86/12 board. Part of the example will be 
written in 8086 assembly language and part in PL/ 
M-86. 

The main program is written in PL/M-86. The 
main program first performs some initialization 
and the matrix multiplication, then the program 
calls an assembly language procedure (subroutine), 
a PL/M-86 procedure and the console output pro- 
cedure CO supplied in the I/O library on the iSBC 
957 diskette. A flow diagram for the example 
program is shown in Figure 6. 

Explanation of the Program Code 

The program code is contained in three software 
modules EXECUTION$VEHICLE, FIND, and 
SBCCO. EXECUTIONSVEHICLE contains the 
main program coded in PL/M-86 and the binary 
to ASCII conversion procedure BIN$DEC$ASC 
also coded in PL/M-86. The module FIND con- 
tains the assembly language procedure FIND$MX 
which searches a matrix for its maximum value. 
The module SBCCO resides in the library of con- 
sole I/O routines supplied with the iSBC 957 pack- 
age. The procedure CO will be used from this 
library. 

The program code for the EXECUTIONSVEHICLE 
and FIND modules will be explained in the follow- 
ing paragraphs. Appendix B contains compilation 
and assembly listings for the two modules; also 
contained in Appendix B is a memory and debug 
map for the linked modules. The listings contain 
circled reference letters (e.g., @) which are referred 
to by the code description below. The listings in the 
appendix have been printed on fold-out pages so 
that they may easily be seen when reading the text. 
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Figure 6. 
Flow Diagram of Matrix Multiplication Example 



Much of the description given below assumes that 
the reader is familiar with the PL/M-86 language 
and compiler, the 8086 assembler, and the link and 
locate program QRL86. It is recommended that the 
reader have at least a cursory knowledge of these 
subjects. The Intel literature for these subjects is 
listed near the front of this application note. 

The EXECUTIONSVEHICLE Module 

(a) The first section of the module includes intro- 
ductory comments and then statements to de- 
clare the matrices, other variables, and pro- 
cedures used in the program. Note that the 
matrix dimensions are declared using the literals 
M, N, and P which are initially set to 6, 5, and 
3. Later in this note, other values for M, N, 
and P will be used. 

(b) The next section of code contains the state- 
ments which initialize the two matrices that will 
be multiplied X$ROW and Y$ROW. 

As a result of this initialization, the two ma- 
trices will contain values as shown in Figure 7. 
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X$ROW (6X5) 

Figure 7. 
X$ROW and Y$ROW Matrices After Initialization 



(c) The next program section performs the matrix 
multiplication. The algorithm required to mul- 
tiply two matrices X and Y, storing the result in 
a third matrix Z is: 



^mp 



n 
i = 1 



mi ^ ip 



Assuming X to be 6X5 matrix and Y a 5X3 
matrix then 

2^11 — ^11 Yi, + X12Y2, + X,3Y3i + X14X41 + X15Y5, 

Thus, the upper left term is equal to the sum of 
the products of the top row of the X matrix 
times the left column of the Y matrix. The re- 
sult that is obtained by multiplying the two 
matrices X$ROW and Y$ROW after they are 
initiahzed as explained above, is shown in 
Figure 8. 
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Figure 8. Result of Multiplying the Initialized Matrices 
X$ROW and Y$ROW 



(5) The external assembly language procedure 
FINDSMX is called to determine the maximum 
value in the matrix. The procedure is a typed 
procedure and returns the maximum value to 
the calling program which stores it in the inte- 
ger variable MAX. 



(e) The maximum value is then converted to a six 
(6) digit ASCII character string by the pro- 
cedure BIN$DEC$ASC. The character string is 
stored in the array MAX$ASC$ ARRAY, which 
contains the sign of the number and five (5) 
digits for the magnitude. 

(f) Finally, the characters **MAX VALUE = " are 
output on the system console followed by the 
6 ASCII characters containing the maximum 
value. The PL/M-86 built-in procedure SIZE 
returns the number of bytes of the array TEXT 
as a word value. The PL/M-86 built-in pro- 
cedure SIGNED changes the type of the value 
from WORD to INTEGER. This is required so 
that the type of the arguments in the DO state- 
ment agree. The console output procedure CO 
is used to output the characters on the system 
console. 

(g) Also contained in the module MATRIX.PLM 
is the binary to ASCII conversion procedure 
BIN$DEC$ASC. The first portion of the code 
contains the comments explaining the para- 
meters and the calling sequence followed by the 
declarations. Note that the address of the array 
where the characters are to be stored is passed 
to the procedure and that the characters will be 
stored in the array using based variables. The 
next section of the code stores either a + or - 
sign in the first character position of the ASCII 
array and stores the absolute value of VALUE 
in the variable TEMP. Finally, the binary value 
is converted to ASCII using the algorithm 
explained in the comments. The MOD operator 
returns the remainder of the division by 10. The 
UNSIGN built-in procedure is required to 
change the type of the expression from INTE- 
GER to WORD. 

The FIND Module 

(h) The FIND module contains the assembly lan- 
guage procedure FINDMX. The calling se- 
quence and the parameters are explained in the 
comments at the beginning of the listing. Note 
that the label FINDMX has been declared 
PUBLIC so the link program can fill in its 
address in the CALL statement in the main 
program of module EXECUTIONS VEHICLE. 

(T) The FIND module will contain three segments: 
a data segment, a stack segment and a code 
segment. It will be both convenient and prag- 
matic to append these three segments to the 
code, data and stack segments created by the 
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compiler for the EXECUTION$VEHICLE 
module. To accomplish this, the three segments 
must be given the same SEGMENT and CLASS 
names as those given these segments by the 
compiler. The SEGMENT and CLASS names 
used by the compiler are CODE, DATA, and 
STACK. The GROUP statements are used to 
place the segments DATA and STACK in the 
group DGROUP and the segment CODE in the 
group CGROUP. These group definitions con- 
form with the group definitions generated by 
the PL/M-86 compiler when the SMALL size 
control option is used. A group is a collection 
of segments which requires less than 64K bytes 
of memory. 

The ASSUME directive informs the assembler 
that the DS and SS registers will contain the 
base address of DGROUP and the CS register 
will contain the base address of CGROUP. 
This information will be used by the assembler 
when constructing machine instructions. 

u) The first segment appearing in the module is 
the data segment. The order of the segments is 
arbitrary, although it is recommended that the 
data segment precede the code segment to mini- 
mize forward references to variables which may 
cause the assembler to generate longer instruc- 
tion codes. The data segment is declared 
PUBLIC, aligned on a WORD boundary and 
given both a segment and class name of DATA. 
Then follows the contents of the segment. In 
this particular example, only one word of stor- 
age is required. The ENDS directive indicates 
the end of the segment. 

(k) Next comes the stack segment which is given 
the segment name of STACK, the combine- 
type attribute of STACK and the class name of 
STACK. The combine-type attribute of STACK 
assures that the stack storage required in this 
module will be appended to the storage re- 
quired in the PL/M-86 compiled modules. Two 
bytes of stack are required by the code in this 
module, however, the monitor uses 13 words of 
stack when breakpoints and interrupts are used. 
Therefore, 14 words are reserved for the stack. 

(h) Finally comes the code segment. The code seg- 
ment has been given a segment name and class 
name of CODE and a group name of 
CGROUP, and has been declared PUBLIC. 
The alignment attribute of BYTE is specified 



since it is desired that the code from this 
module be appended directly to the code from 
other modules without gaps between the code 
modules. 

The assembly language code follows next. The 
code for the procedure must be enclosed be- 
tween a pair of PROC, ENDP statements. The 
PROC statement is given the label FINDMX 
and specified as a NEAR procedure indicating 
it will be called with a near (intra-segment) 
CALL instruction and not a far (inter-segment) 
CALL instruction. 

The comments at the beginning of the module 
and adjacent to the program statements ex- 
plain the function being performed by the 
assembly language code. 

The SBCCO Module 

(M) The console output procedure CO is contained 
in the object module SBCCO of the library file 
SBCIOS.LIB. SBCIOS.LIB is part of the iSBC 
957 package I/O libraries. The calling sequence 
and parameters for CO may be seen in the 
external procedure declaration in the EXE- 
CUTIONSVEHICLE module. 

Compiling the EXECUTION$VEHICLE 
Module 

The EXECUTION$VEHICLE module is stored on 
a file named MATRIX. PLM on disk device :F1:. 
To compile the module, the following command 
line is used: 

-PLM86 :F1:MATRIX.PLM DEBUG 

This command line will cause the module stored in 
the file :F1:MATRIX.PLM to be compiled. The 
object code generated will be stored in a file with 
the default name :Fl:MATRIX.OBJ and the Usting 
generated will be stored in a file with the default 
name :F1:MATRIX.LST. To override the default 
object and listing files, the NOOBJECT and NO- 
LIST compiler control switches can be used. File 
names for the listing and object files may also be 
specified in the command line. The DEBUG com- 
piler control switch causes the compiler to generate 
extra symbol and line number information which 
will be used during debugging of the program. A 
listing of the compiled EXECUTION$VEHICLE 
module is contained in Appendix B. 

To aid in the debugging of the program, the 
module was compiled a second time with the fol- 
lowing command Une: 
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- PLM86 :F1:MATRIX.PLM NOOBJECT 
CODE DEBUG PRINT (:F1:MATRIX.XLS) 

This command line specified that no object file is to 
be created and a listing file should be stored in the 
file :F1:MATRIX.XLS. The CODE compiler con- 
trol switch causes the compiler to list the assembly 
language statements which the compiler has gener- 
ated for each line of PL/M code. The listing stored 
in the file MATRIX.XLS is contained in Appendix 
C. 

Assembly of the FIND Module 

The assembly language module FIND is stored on a 
file named FIND. ASM, to assemble this module 
the following command line is used: 

ASM86 :F1:FIND.ASM DEBUG 

This command line will cause the FIND module to 
be assembled with the object code stored in the 
default file :Fl:FIND.OBJ and the listing stored in 
the default file :F1:FIND.LST, The listing of the 
assembled FIND module is contained in Appendix 
B. 

Linking and Locating the Object Module 

To link and locate the object modules, the QRL86 
program will be used. The QRL86 program per- 
forms both the linking and the locating of the 
object modules in a single step. QRL86 is primarily 
designed for the debugging stages of program devel- 
opment. Some applications may require the extended 
capabilities of the separate LINK and LOCATE 
programs when the final link and locate is per- 
formed. The command line used to invoke the 
QRL86 program is: 

QRL86 :Fl:MATRIX.OBJ, :Fl:FIND.OBJ, 
SBCIOS.LIB ORIGIN (lOOOH) 

This command line will cause QRL86 to link the 
code from the three modules and to locate the 
resultant absolute object module starting at location 
1000 hexadecimal. The iSBC 86/12 monitor uses 
the first 180H bytes of memory for the monitor 
stack, data and interrupt vectors, lOOOH was chosen 
as a convenient starting address for the program. 
The absolute object code will be stored in a default 
file :F1:MATRIX (note no file name extension is 
used). By default, the memory and debug maps 
which are generated are stored in the file :F1:MA- 
TRIX.MPQ and are contained in Appendix B. 

M) The memory map contains the starting ad- 
dresses and sizes of the CODE, CONST, 
DATA, STACK and MEMORY segments of 
the object module. Note that the start address 



for the program is specified as (0100H, 0002H) 
indicating a CS value of 01f)0H and an IP 
value of 0002H or an absolute value of 01002H. 
The first two bytes of the code segment contain 
address values which the code generated by the 
compiler will use for setting up the DS and SS 
registers. The memory map shows the code 
segments from the three modules collected into 
the group CGROUP. The code segment from 
the EXECUTIONSVEHICLE module is given 
the segment and class names of CODE and is 
put into CGROUP by the PL/M compiler. To 
assure that the code segment from the FIND 
module is concatenated with the code segment 
from the EXECUTIONSVEHICLE module the 
identical class, segment and group names were 
specified in the SEGMENT and GROUP state- 
ments in the FIND module. Next, the group 
DGROUP is shown in the memory map. 
DGROUP contains 4 segments labelled 
CONST, DATA, STACK and MEMORY. 
Putting all of these segments in the same group 
tells the linker that they will all be in the same 
64K block of memory. The SMALL size con- 
trol option of the compiler, which was invoked 
by default, creates CGROUP, DGROUP, and 
the segments contained in them. 
(p) The debug map contains the memory address 
of variables, instruction labels and the ad- 
dresses of each code Hne of the PL/M-86 
module. Notice that the variable storage labels 
have their addresses specified in the format (DS 
register value, displacement). For example, the 
variable TEMP has an address of DS=012AH, 
displacement = 000CH or an absolute address 
of 0136H. Instruction labels and line numbers 
use the format (CS register value, IP register 
value). Thus, line number six (6) in the module 
EXECUTIONSVEHICLE has the address 
CS=0100H, IP=0B5H or 01 1B5H. 

Object to Hex Conversion 

Before downloading the program to the iSBC 86/12, 
the format of the object module must be converted 
from the absolute object module format which 
QRL86 creates to a hexadecimal/ASCII representa- 
tion of the object module. This is done using the pro- 
gram OH86 with the following command line: 

OH86 :F1:MATRIX TO :F1:MATRIX.HEX 

Downloading and Debugging the Program 

The hardware configuration used for debugging the 
matrix multiplication example program code was 
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an Intellec Series II Model 230 development sys- 
tem, the iSBC 957 package, an iSBC 86/12 board, 
and an iSBC 660 system chassis. What follows is 
the system-user dialog for a typical debugging 
session. 

The first step required is to bootstrap load the 
ISIS-II operating system by hitting the RESET 
switch of the Intellec. The Intellec resident loader 
software is then loaded and executed. Throughout 
the dialog which follows operator entered charac- 
ters will be underlined: 

ISIS-II, V3.4 
-SBC861 

ISIS-II ISBC 86/12 LOADER, VI . 2 

To initialize the iSBC 86/12 monitor, the user must 
hit the RESET switch on the iSBC 660 chassis and 
type two "U"s on the system console. The monitor 
program will output a line on the console when it is 
properly initialized. 

ISBC 86/12 MONITOR, VI. 2 

The monitor command "X" is typed to check that 
the monitor is properly operating and to examine 
the contents of the 8086 registers. 
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The PL/M-86 compiler ends the main program in 
the EXECUTION$VEHICLE module with a halt 
instruction. After execution of the program it is 
more desirable to return to the monitor. To ac- 
complish this, an INT 3 instruction (code=CC) 
will be substituted for the halt instruction (code= 
F4) at the address of 1B4H relative to a CS value 
of lOOH. First the "D" command is used to verify 
the address of the halt instruction, then the "S" 
command is used to change the instruction to an 
INT 3 instruction. 



. D1B4 
01B4 F4 
. S1B4, F4- CC 



AX=0000 BX=0000 CX=0000 DX=0000 SP=01C0 BP=0000 SI=0000 
DI=0000 CS=0000 DS=0000 SS=0000 ES=0000 IP=0000 FL=0000 



To download the hex object file to the iSBC 
86/12, the "L" command is used. Because an 
Intellec Series II Model 230 is being used, a serial 
download is specified. The hex file name is 
MATRIX. HEX which is resident on disk device 
:F1:. 

■ LS, :F1: MATRIX. HEX 



To execute the PL/M-86 main program, the "G" 
command is used. After the **G" is typed, the 
current contents of the IP are output, followed by 
the contents of the byte pointed to by the IP. A 
new value for the IP or breakpoint addresses may 
be specified before a carriage return <CR> is typed. 
In this example, only a <CR> is typed. 



.G 0002- FA 
MAX VALUE = -0 50 
@0100:01B5 55 



The "X" command is used again to examine the 
CPU registers. Note that the monitor has changed 
the contents of the CS and IP registers to the value 
of the starting address of the program. 



AX=0000 BX=0000 CX=0000 .DX=0000 SP=01C0 BP=0000 31=0000 
DI=0000 CS = 0100 DS=00'^0 SS=0000 ES = 0000 IP = 0002 FL=0000 



The "D" command is next used to display the first 
101 bytes of the program code. Unless another seg- 
ment register is specified, the display command 
assumes all addresses specified are relative to the CS 
register. Thus, the code displayed will be from abso- 
lute addresses 1000 through 1 100. The program code 
displayed may be compared with program code gen- 
erated by the PL/M-86 compiler shown in Appendix 
C, code line 36. 



The program executes and outputs the maximum 
value of the matrix calculated. The INT 3 instruc- 
tion is executed which causes a return to the 
monitor. The monitor types out an at-sign (@) 
followed by the CS and IP register values and the 
first byte of the instruction following the INT 3 
instruction. 

The ''X" command is typed to examine the CPU 
registers. Note that the program has set both the SS 
and DS registers to 01 2A. (012A0H is the address 
of the DGROUP as shown in the memory map.) 



AX=0030 BX=0005 CX=000A DX=0000 SP=00D0 BP=00D0 31=0001 
DI=0006 CS=0100 DS=012A SS=012A E3=0000 IP=0lB5 FL=F202 



The three matrices are displayed. Note that a word 
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display has been specified by using the "DW" 
Command and that the addresses have been speci- 
fied relative to the DS register. The addresses of 
X$ROW, Y$ROW, and Z$ROW may be found in 
the debug map given by QRL86. Note that the 
values stored in the matrices are the same as those 
shown in Figures 8 and 9. 

. DW DS:10,4A 
0010 0000 0000 0000 0000 0000 0001 0001 0001 
0020 0001 0001 0002 0002 0002 0002 0002 0003 
0030 0003 0003 0003 01^03 0004 0004 0004 0004 
0040 0004 0005 0005 0005 0005 0005 
■DW DS:4C,68 
004C 0000 FFFF 

0050 FFFE 0000 FFFF FFFE 0000 FFFF FFFE 0000 
0060 FFFF FFFE 0000 FFFF FFFE 
. DW DS;6A,8C 
006A 0000 0000 0000 

0070 0000 FFFB FFF6 0000 FFF5 FFEC 0000 FFFl 
0080 FFE2 0000 FFEC FFD8 0000 FFE7 FFCE 



The "G" Command is used to reset the IP register 
to the start address of the program (002) and to 
specify a breakpoint at address 0AEH, which is the 
address of statement 57 of the main program. 
Statement 57 is the point in the program after the 
X$ROW and Y$ROW matrices have been initial- 
ized, but before the matrix multiplication is 
performed. After the <CR> is typed, the program 
executes until the breakpoint is encountered. At 
this point, the monitor outputs a line specifying 
the number of the breakpoint, the CS and IP 
values and the first byte of the next instruction to 
be executed. 

.G 01B5- 55 002, AE 
BRl (aO100:O0AE C7 

Next, the single-step capability is used with the 
"N" command to execute single instructions. At 
any time, CPU registers may be examined or 
changed. In this example, the "X" command is 
used. Execution of succeeding instructions is caused 
by typing a comma (,). 

.N 00AE- C7 j_ 

0084- 81 j_ 

00BA- 7E j_ 

00BF- C7 
.X 

AX=0018 BX=0018 CX=FFfE DX=00O0 SP=00D0 BP=0OD0 SI=0004 

DI=0006 CS=0100 DS=012A SS=012A ES=0000 IP=00BF FL=F293 
.N O0BF- CI _, 

00C5- 81 ^ 

00CB- 7E 

The contents of the X$ROW and Y$ROW matrices 
are examined and changed with the "SW" (sub- 
stitute word) command. If a comma (,) is typed 
after the contents of memory are displayed, then 
the contents are left unchanged and the next word 
of memory is displayed. If a value followed by a 
comma or <CR^ is entered, then the contents are 
changed. If a <CR> is entered, the substitute 



sequence is terminated. 



. SW DS:1A, 0001- 
001C 0001- _, 
001E 0001- 10 
. SW DS:5A, FFFF- 
005C FFFE- _, 
005E 0000- ^ 
0060 FFFF- 64 



After the matrices are modified, execution is 
resumed with the "G" command. The max value is 
output and the INT 3 instruction executed. Finally, 
the contents of the 3 matrices are displayed. 

.G 00CB- 7E 
MAX VALUE = +00480 
Cd0100:OlB5 55 
■ DW DS:10,8C 

0010 0000 0000 0000 0000 0000 0001 0001 0010 

0020 0001 0001 0002 0002 0002 0002 0002 0003 

0030 0003 0003 0003 0003 0004 0004 0004 0004 

0040 0004 0005 0005 0005 0005 0005 0000 FFFF 

0050 FFFE 0000 FFFF FFFE 0000 FFFF FFFE 0000 

0060 0064 FFFE 0000 FFFF FFFE 0000 0000 0000 

0070 0000 0051 FFD8 0000 00C0 FFEC 0000 0120 

0080 FFE2 0000 0180 FFDB 0000 01E0 -FFCE 



Expanding the Example Program's 
Memory Requirements 

To illustrate how the iSBC 86/12 board may be 
used for executing 8086 programs which require 
large amounts of RAM, the example program will 
be modified. The matrix dimensions of the example 
will be changed from values of 6, 5 and 3 for the 
hteral symbols of M, N, and P to values of 100, 
50, 70. The three matrices will then be of size 
100X50, 50X70, and 100X70. The memory re- 
quired for these matrices is 15.5K words or 3 IK 
bytes. The data, constant, stack and memory 
segments which are contained in the group 
DGROUP will now comprise almost 32K bytes of 
memory. 

The extra memory requirements will be supplied 
by using an iSBC 032 board with the iSBC 86/12 
board in the iSBC 660 chassis. The iSBC 032 board 
is a 32K byte RAM board which is compatible 
with both 8- and 16-bit CPU boards. The base 
address of the board may be selected anywhere in 
a to 1 megabyte range on any 16K byte boundary. 
8- or 16-bit data transfers may be selected. The 
iSBC 032 board will be jumpered to respond to 
addresses in the 512K or 544K address space (20 
bit hex address range to 80000H to 87FFFH). This 
will illustrate the capabilities of the 8086 to access 
a 20-bit, 1 megabyte address range. 

One other modification is required to the program. 
The magnitude of the numbers which would result 
from multiplying matrices of this size would great- 
ly exceed the capacity of the 16-bit integer storage, 
even with the two matrices initialized to the small 
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values they presently contain. To keep the example 
simple, the initialization values will be changed so 
all elements of the X$ROW matrix are set equal to 
2 and all elements of the Y$ROW matrix are set 
equal to 3. The result of the multiplication should 
make all the elements of Z$ROW equal to 300. 

The modified Hues of program code are shown 
below. 



/* MATRIX DIMENSIONS. */ 

27 1 DECLARE M LITERALLY '100'; 

28 1 DECLARE N LITERALLY '50'; 

29 1 DECLARE P LITERALLY '70'; 



The object code is then converted to hex format 
and downloaded to the iSBC 86/12 board. When 
the program is executed, the maximum value is 
calculated and output on the console. 



- S3C861 

ISIS-II ISBC 86/12 LOADER, VI . 2 

ISBC 86/12 MONITOR, , VI. 2 
■ LS, ;F1;MATRIY.HEX 

. SlAC, F4- CC 

.G 0002- FA 

MAX VALUE = +00300 

@0100:01AD 55 



37 
38 
39 



43 
44 



DO I = TO (M-1) ; 
DO J = TO (N-1) ; 

X$ROW{I) .COL(J) = 2; 

END; 
END; 



DO I = TO (N-l) ; 

DO J = TO (P~l) ; 
Y$ROW(I) .COL(J) = 

END; 
END; 



The EXECUTION$VEHICLE module must be re- 
compiled and then the three program modules must 
be linked and located using the QRL86 program. 
Specifying the SEGMENTS option of QRL86, the 
origin of the CODE segment which is in the group 
CGROUP is set at lOOOH, as in the first example. 
However, the origin of the CONST, DATA 
STACK and MEMORY segments which make up 
the group DGROUP is set at 80000H. 

QRL86:Fl:MATRIX.OBJ,:Fl:FIND.OBJ, 
SBCIOS.LIB SEGMENTS (CODE(IOOOH), 
CONST (80000H), DATA STACK, MEMORY) 

The memory map generated by QRL86 shows the 
CGROUP having a start address of OlOOOH and 
the DGROUP having a start address of 80000H. 

INVOKED BY: 

QRL86 :F1:MATRIY. OBJ, :F1:FIND. OBJ, SBCIOS.LIB & 

SEGMENTS (CODE(1000H) ,CONST (80000H ) , DATA , STACK , MEMORY) 

INPUT MODULES INCLUDED: 
:F1:MATRIY.0BJ (EXECUTIONVEHICLE) 
:F1:FIND.0BJ(FIND) 
SBCIOS.LIB(SBCCO) 

RESULT WRITTEN TO : Fl : MATRIY ( EXECUTIONVEHICLE) 
START ADDRESS IS ( 100H , 000 2H ) 

START LTH ALIGN NAME CLASS 



01000H 


298H 


Q 


/GS/ CGROUP 




01000H 


21DH 


W 


CODE (EXECUTIONVEHICLE) 


CODE 


0121DH 


41H 


B 


CODE (FIND) 


CODE 


0125EH 


BAH 


W 


CODE(SBCCO) 
/GE/ CGROUP 


CODE 


80000H 


7970H 


G 


/GS/ DGROUP 




80000H 


CH 


W 


CONST (EXECUTIONVEHICLE) 


CONST 


8000CH 


0H 


W 


CONST (SBCCO) 


CONST 


8000CH 


792AH 


w 


DATA (EXECUTIONVEHICLE) 


DATA 


87936H 


2H 


w 


DATA (FIND) 


DATA 


87938H 


0H 


w 


DATA (SBCCO) 


DATA 


87940H 


30H 


sw 


STACK 


STACK 


87970H 


0H 


w 


MEMORY 
/GE/ DGROUP 


MEMORY 


87970H 


0H 


G 


??SEG(FIND) 


(NULL) 



VI. CONCLUSION 

This application note has described the iSBC 957 
Intellec— iSBC 86/12 Interface and Execution 
Package, and how this package may be used to 
develop and debug programs for the 8086 processor. 
First, the iSBC 86/12 single board computer was 
described, followed by a detailed description of the 
iSBC 957 package and the iSBC 86/12 system 
monitor commands. The power and versatility of 
the iSBC 957 package and monitor commands for 
developing and debugging programs for the 8086 
were illustrated by a program example. In the 
example a program which consisted of PL/M-86 
and assembly language routines was presented. The 
program code was explained, and the steps required 
to compile, assemble, link, locate, and debug the 
program were illustrated. Finally, a typical de- 
bugging session using the iSBC 86/12 system moni- 
tor which illustrates the powerful capabilities of the 
monitor was presented. 
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APPENDIX B 
PROGRAM LISTINGS FOR EXECUTION$VEHICLE AND FIND MODULES 
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r 



PL/M-86 COMPILER EXECUTIONVEHICLE 



ISIS-II PL/M-86 VI. COMPILATION OF MODULE EXECUTIONVEHICLE 

OBJECT MODULE PLACED IN : PI :MATRIX. OBJ 

COMPILER INVOKED BY: PLM8f5 :F1 :MATRIX. PLM DEBUG 



MATRIX MULTIPLICATION EXAMPLE PROGRAM 



PL/M-86 MAIN PROGRAM WHICH: 

A) INITIALIZES TWO INTEGER MATRICES 

B) MULTIPLIES THE TWO MATRICES AND STORES THE RESULT IN A 
THIRD MATRIX 

C) CALLS AN ASSEMBLY LANGUAGE PROCEDURE WHICH SEARCHES THE 
THIRD MATRIX FOR THE MAXIMUM VALUE 

D) CALLS A PL/M PROCEDURE WHICH CONVERTS THE MAXIMUM VALUE 
FROM INTEGER TO ASCII 

E) CALLS A PROCEDURE WHICH OUTPUTS THE ASCII CHARACTERS ON 
THE SYSTEM CONSOLE 



EXECUTIONSVEHICLE: 



/* FINDi^MX - EXTERNAL ASSEMBLY LANGUAGE PROCEDURE WHICH SEARCHES 
MATRIX FOR THE LARGEST ABSOLUTE MAGNITUDE. 
PARAMETERS: 

MATRTX$ADR - ADDRESS OF THE MATRIX TO BE SEARCHED 
ROWS - NUMBER OF ROWS IN THE MATRIX 
COLS - NUMBER OF COLUMNS IN THE MATRIX 



FIND$MX: PROCEDURE (MATRIX$PTR, 
DECLARE (ROWS, COLS) INTEGER; 
DECLARE MATRIXSPTR POINTER; 
END FINDSMX; 



ROWS, COLS) INTEGER EXTERNAL; 



© 



© 



Ifi 
17 



/* BIN<:DEC$ASC - BINARY TO DFCIMAL ASCII CONVERSIOM PROCEDURE 
PARAMETERS: 

VALUE - INTEGER VALUE TO BE CONVERTED TO ASCII 
CHAR?ARRAY$ADR - ADDRESS OF 6 BYTE ARRAY WHERE ASCII 
STRING CONTAINING THE VALUE WILL BE STORED 
V 
BIN!?DEC$ASC: PROCEDURE (VALUE, CHARSARRAYSADR) ; 

DECLARE (VALUE, TEMP, I) INTEGER; 

DECLARE CHAR?;ARRAy$ADR POINTER; 

DECLARE (CHAR?ARRAY BASED CHAR?ARRAY$ADR) (6) BYTE; 

IF VALUE < THEN 
DO; 

CHAR$ARRAY(P) = ' 

TEMP = -VALUE; 
END; 
ELSE 
DO; 

CHAR:^ARRAY(P) = •+•; 

TEMP = VALUE; 
END; 
DO T = 5 TO i BY -1; 

CHAR$ARRAY (I) = UNSIGN(TEMP MOD IP) 

TEMP = TEMP/IP; 

/* ASCII CHARACTERS ?(1 THRU 39 HEX REPRESENT THE DIGITS THRU 9. THUS 
TO CONVERT AN INTEGER TO ASCII REPEATED DIVISIONS BY 10 AND ADDING 
THE REMAINDER TO ?B HEX WILL ACCOMPLISH THE CONVERSION */ 
END; 

END BIN?DEC$ASC; 



/* SIGN CHARACTER */ 



3 m ; 



©^ 



/* CO - EXTERNAL PROCEDURE TO OUTPUT A CHARACTER TO THE SYSTEM CONSOLE. 

THIS PROCEDURE IS PART OF THE TSBC 957 LIBRARY FOR CONSOLE I/O 

PARAMETER: 

CHAR - ASCII CHARACTER TO BE OUTPUT ON THE CONSOLE 
*/ 

CO: PROCEDURE (CHAR) EXTERNAL; 
DECLARE CHAR BYTE; 
END CO; 



V 



30 
31 
3 2 



/* MATRIX DIMENSIONS */ 
DECLARE M LITERALLY '6'; 
DECLARE N LITERALLY '5'; 
DECLARE P LITERALLY '3'; 

/* THE THREE MATRICES ARE DECLARED AS ARRAYS OF STRUCTURES. XSROW IS COMPOSED 
OF M STRUCTURES EACH OF WHICH IS COMPOSED OF N INTEGER ELEMENTS. THUS 
XSROW MAY BE THOUGHT OF AS A M X N MATRIX. THE MATRIX WILL BE STORED AS 
A ROW-ORDER MATRIX WITH THE ELEMENTS OF EACH ROW STORED IN ADJACENT MEMORY 
LOCATIONS. Y?ROW IS DECLARED AS A N X P MATRIX AND Z$ROW AS A N X P MATRIX */ 

DECLARE X$ROW(M) STRUCTURE (COL(N) INTEGER); 

DECLARE Y$ROW(N) STRUCTURE (COL(P) INTEGER); 

DECLARE Z$ROW(M) STRUCTURE (COL(P) INTEGER); 

DECLARE (I, J, K, MAX) INTEGER; 

DECLARE MAX$ASC$ARRAY(fi) BYTE; 

DECLARE TEXT(*) BYTE DATA ('MAX VALUE = '); 
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/* INITIALIZE XSROW SUCH THAT THE FIRST ROW IS SET EQUAL TO K, THE SECOND 

ROW EQUAL TO 1, THE THIRD ROW EQUAL TO 2, ETC. */ 
DO I = TO fM-1) ; 
DO J r. i" TO (N-1) ; 

X^ROWd) .COL (J) = I ; 
END; 
END; 

/* INITIALI7E YSROW SUCH THAT THE FIRST COLUMN IS SET EQUAL TO 0, THE 

SECOND COLUMN EQUAL TO -1, AND THE THIRD COLUMN EQUAL TO -2. */ 
DO I = TO (N-1) ; 
DO J = TO fP-1 ) ; 

YSROW (I) .COL (3) = -J; 
END; 
END; 

/* PERFORM MATRIX MULTI PLICATI OS' */ 
DC K = TO (P-I) ; 
DO I = TO (M-1) ; 

Z$ROW(I) .COL(K) = 0; /* SET Z$ROW ELEMENT TO */ 

DO J = TO (N-1); /* SUM THE PRODUCT OF XSROW ROW TERMS AND Y$ROW COLUMN TERMS */ 

Z$ROW(I) .COL(K) = ZSROWd) .COL (K) + ( XSROW ( I ) . COL ( J ) * Y$ROW (J ) . COL (K) ); 
END; 
END; 
END; 

MAX = FINDSMX (PZCROW, M, P); /* FIND MAX VALUE OF ZSROW */ 

CALL BINSDECSASC (MAX, (aMAXSASC$ARRAY) ; /* CONVERT TO DECIMAL ASCII */ 

DO I = TO (SIGNED(SIZE (TEXT) ) - 1); /* OUTPUT HEADER TEXT */ 

CALL CO (TEXT (I) ) ; 
END; 



DO I = TO 5; /* OUTPUT ASCII MAX VALUE */ 

CALL CO(MAX$ASC$ARRAY(I) ) ; 
END; 



END EXECUTION$VEHICLE; 



MODULE INFORMATION: 

CODE AREA SIZE 
CONSTANT AREA SIZE 
VARIABLE AREA SIZE 
MAXIMUM STACK SIZE 
]37 LINES READ 
PROGRAM ERROR (S) 

END OF PL/M-86 COMPILATION 



0225H 


54 9D 


fl00CH 


12D 


009OH 


]44D 


0O08H 


PD 



ISIS-II MCS-8fi ASSEMBLER ASSEMBLY OF MODULE FIND 
OBJECT MODULE PLACED IN ;F1:FIND.0BJ 
ASSEMBLER INVOKED BY: ASM86 :F1:FIND.ASM DEBUG 



© 



33 

34 



NAME FIND 
PUBLIC FINDMX 



FINDMX 
ASSEMBLY LANGUAGE PROCEDURE TO FIND THE ELEMENT OF AN INTEGER 
MATRIX WITH THE LARGEST ABSOLUTE MAGNITUDE. THE VALUE OF THE 
ELEMENT IS RETURNED IN THE AX REGISTER. 



PL/M CALLING SEQUENCE: 

MAX$VALUE = FIND$MX(ADR$OF$MATRIX, #$OF$ROWS, 



#$OF$COLS) ; 



PARAMETERS: 

ADR$OF$MATRIX - ADDRESS OF THE MATRIX WHICH WILL 
#$OF$ROWS - NUMBER OF ROWS IN THE MATRIX 
#$OF$COLS - NUMBER OF COLUMNS IN THE MATRIX 



IE SEARCHED 



PL/M WILL PASS THE THREE PARAMETERS IN THE CALL TO THIS PROCEDURE ON 

THE STACK. ON ENTRY TO THE PROCEDURE SP+6 WILL POINT TO THE FIRST 

PARAMETER (ADR$OF$MATRIX) AND SP+4 AND SP+2 WILL POINT TO THE SECOND 
AND THIRD PARAMETERS. 

THE PROCEDURE IS A TYPED PROCEDURE WHICH ASSIGNS THE MAXIMUM VALUE 
IN THE MATRIX TO A VARIABLE (IN THIS CASE MAX$VALUE) IN A PL/M 
ASSIGNMENT STATEMENT. TO ACCOMPLISH THIS ASSIGNMENT THE VALUE IS 
RETURNED IN THE AX REGISTER. 

THE ALGORITHM USED IS SIMILAR TO THE FOLLOWING PL/M CODE: 
FOR I = TO (#$OF$ROWS - 1); 
FOR J = TO (#$OF$COLS - 1); 

IF IABS(MATRIX (I) .Y (J) ) > IABS{MAX) THEN MAX = MATRIX ( I) . Y ( J) ; 
END; 
END; 

WHERE lABS(XYZ) REPRESENTS THE ABSOLUTE VALUE OF THE INTEGER XYZ 
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0f;06[] 


00(14 n 


0008[] 


0P00 




0000 


55 


001 


OBEC 


0003 


33D2 


0005 


8BFA 


0007 


8BF2 


0009 


89160000 


000D 


8B4E04 


0010 


DlEl 


0012 


PB5E08 


00 J 5 


8B00 


0017 


0BC0 


0019 


7902 


fi01B 


F7D8 


ID 


3BC? 


00]F 


7C07 


0021 


8BD0 


0023 


8B00 


0025 


A30000 


0028 


83C602 


002B 


3BF1 


002D 


72E6 


3 2F 


8D18 


003J 


BE0000 


003-^ 


47 


0035 


3B7E06 


0038 


72DB 


003A 


A10000 


003D 


5D 


003E 


C20600 



41 
42 



51 
52 
53 



51 
62 



64 
55 



59 

70 
71 



78 
79 
80 
81 
82 



DEFINE GROUPS TO CONFORM WITH PL/M-86 CONVENTIONS. DATA, STACK, AND 
CODE SEGMENTS WILL BE APPENDED TO THEIR RESPECTIVE SEGMENTS IN THE 
PL/M-86 MODULES. 

DGROUP GROUP DATA, STACK 

CGROUP GROUP CODE 

INSTRUCT THE ASSEMBLER THAT THE DS , SS, AND OS REGISTERS WILL CONTAIN 
THE BASE ADDRESS VALUES FOR THE DGROUP, DGROUP AND CGROUP GROUPS. 
ASSUME DS : DGROUP, SS: DGROUP, CS: CGROUP 



»************DATA SEGMENT 

DATA SEGMENT WORD PUBLIC ' 
MAX DW 
DATA ENDS 



95 
96 



101 
102 
103 
104 
105 
106 
107 
108 
109 
110 
111 
112 



*STACK SEGMENT 



STACK SEGMENT STACK 'STACK' 
DW 14 DUP (0) 



;RESERVE 13 WORDS OF STACK FOR MONITOR 



;AND 1 WORD FOR FINDMX PROCEDURE 



CODE 



***«*****CODE SEGMENT 
SEGMENT BYTE PUBLIC 'CODE' 



; PARAMETERS ON STACK, 
NO_OF_ROWS EQU 
NO OF COLS EQU 
ADR OF MATRIX EQU 



FINDMX 



PROC 

PUSH 

MOV 

XOR 

MOV 

MOV 

MOV 

MOV 

SHL 



JNS 

NEG 

CMP 

JL 

MOV 

MOV 

MOV 

ADD 

CMP 

JB 

LEA 

MOV 

INC 



MOV 
POP 
RET 

INDMX ENDP 

ODE ENDS 

END 



DISPLACEMENT FROM TOS INCREASED BY TWO DUE TO INITIAL PUSH 
WORD PTR [BP+6] 
WORD PTR [BP+4] 
WORD PTR [BP+8] 



NEAR 

BP 

BP,SP 

DX,DX 

DI,DX 

SI,DX 

MAX,DX 

CX,NO_OF_COLS 

CX,1 

BX,ADR_OF_MATRIX 

AX, [BX] [SI] 

AX, AX 

DEF 

AX 

AX,DX 

XYZ 

DX , AX 

AX, [BX] [SI] 

MAX, AX 

SI, 2 

SI,CX 

ABC 

BX,[BX+SI] 

SI,0 

DI 

DI,NO OF ROWS 

ABC 

AX, MAX 

BP 



PROCEDURE DECLARATION 

SAVE BP REGISTER 

BP POINTS TO PARAMETERS ON STACK 

SET DX = ABS OF CURRENT MAX = 

DI = I (ROW INDEX) = 

SI = J (COLUMN INDEX) = 

MAX = CURRENT MAX = 

CX = (#$OF$COLS) * 2 
TERMINATION FOR J (SI ) INDEX 

;ADR$OF$MATRIX PARAMETER 
BX POINTS TO FIRST ELEMENT OF A GIVEN ROW 
GET ELEMENT OF MATRIX 
SET FLAGS 
JUMP IF SIGN = 
NEGATE TO FORM POSITIVE NUMBER 
COMPARE TO CURRENT MAX 
JUMP IF LESS THAN CURRENT MAX 
MOVE TO ABS OF CURRENT MAX 
MOVE MATRIX VALUE TO CURRENT MA-". 

INCREMENT J INDEX BY TWO 

END OF THIS ROW ?? 

IF NO, LOOP BACK FOR NEXT ELEMENT OF THIS ROW 

BX = BX + (2 * #$OF$COLS), BX POINTS TO NEXT ROW 

J = 

1 = 1 + 1 

LAST ROW ?? 

IF NO, DO THE NEXT ROW 

RETURN MAX VALUE IN AX REGISTER 

RESTORE BP REGISTER 

INCREMENT SP BY 6 AND RETURN TO CALLER 



SYMBOL TABLE LISTING 



VALUE ATTRIBUTES 



??SEG . . . . 


SEGMENT 




SIZE=0000H PARA 


PUBLIC 


ABC 


L NEAR 


001 5H 


CODE 




ADR OF MATRIX 


V WORD 


0008H 


[BP] 




CGROUP. . . . 


GROUP 




CODE 




CODE 


SEGMENT 




SIZE=0041H BYTE 


PUBLIC 'CODE 


DATA 


SEGMENT 




SIZE=0002H WORD 
CODE 


PUBLIC 'DATA 


DEF .... 


L NEAR 


001DH 


DGROUP. . . 


GROUP 




DATA STACK 




FINDMX. . . 


L NEAR 


ee00H 


CODE PUBLIC 




MAX ... . 


V WORD 


0000H 


DATA 




NO OF COLS. 


V WORD 


0004H 


[BP] 




NO OF ROWS. 


V WORD 


0006H 


[BP] 




STACK . . . 


SEGMENT 




SIZE=P01CH PARA 


STACK 'STACK' 


XYZ .... 


L NEAR 


0028H 


CODE 





ASSEMBLY COMPLETE, NO ERRORS FOUND 
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INVOKED \\\: 

ORLF''. :F] : MATRIX. OBJ, :F] : F IMD. OR J , .Sf3C lOS . LIB OR IG IN ( 1 0CCH ) 

TNPUT MODULES INCLUDED: 

:F1 : MATRIX. OR J f FXFCUTI ONVEMICLE ^ 

:F1 .-FIND. OBJ (FIND) 

SBCIOS.LIB(SBCCO} 

RESULT WRITTEN TO : F.1 : MATRI X (EXECUTTONVEHICLE ) 
START ADDRESS IS ( 1 P OH , P"n 2H ) 

START LTH ALIGN NAME CLASS 



PI10OPH 


2A0H 


G 


/GS/ CGROUP 




01HC^0H 


2 2 5H 


W 


CODE (EXECUTIONVEHICLE) 


CODE 


01225H 


4 1H 


B 


CODE(FIND) 


CODE 


f"126GH 


3AH 


W 


CODEfSBCCO) 
/GE/ CGROUP 


CODE 


fll2Af"H 


D0H 


G 


/GS/ DGROUP 




012A0H 


CH 


W 


CONST (EXECUTIONVEHICLE) 


CONST 


r'12ACH 


0H 


V\f 


CONGT(SPCCO) 


CONST 


012ACH 


90H 


W 


DATA (EXECUTIONVEHICLE) 


DATA 


0133CH 


2n 


V 


DATA (FIND) 


DATA 


0133EH 


0H 


w 


DATA(SBCCO) 


DATA 


01340H 


?0H 


SW 


STACK 


STACK 


01370H 


0H 


w 


MEMORY 
/GE/ DGROUP 


MEMORY 


37 0H 


0H 


G 


??SEG(FIND) 


(NULL) 



DEBUG MAP OF : Fl : MATRIX (EXECUTIONVEHICLE ) 



© 







MODULE: 


EXECUTIONVEHICLE 


0100H, 


01E1H 


LINE 




19 


0:2AH 


00D0H 


SYMBOL: 


MEMORY 


010CH 


01FBH 


LINE 




20 


0100H 


01B5H 


SYMBOL: 


BINDECASC 


0100H 


fi21?H 


LINE 




21 


012AH 


000CH 


SYMBOL: 


TEMP 


0100H 


021EH 


LINE 




22 


012AH 


000EH 


SYMBOL: 


I 


0100H 


0221H 


LINE 




23 


012AH 


0010H 


SYMBOL: 


XROW 


0100H 


0002H 


LINE 




36 


012AH 


004CH 


SYMBOL: 


YROW 


0100H 


0P21H 


LINE 




37 


012AH 


006AH 


SYMBOL: 


ZROW 


0100H 


0032H 


LINE 




3 8 


012AH 


008EH 


SYMBOL: 


I 


0100H 


004BH 


LINE 




"^9 


012AH 


0090H 


SYMBOL: 


J 


0100H 


005^H 


LINE 




^0 


0.1 2AH 


0092H 


SYMBOL: 


K 


0100H 


005DH 


LINE 




A\ 


012AH 


0094H 


SYMBOL: 


MAX 


r]00H 


00fEH 


LINE 




n. 


012AH 


009r,H 


SYMBOL: 


MAXASCARRAY 


010 0H 


007FH 


LINE 




M, 


012AH 


0000H 


SYMBOL: 


TEXT 


0100H 


009CH 


LINE 




ti\ 


0100H 


01B5H 


LINE #: 


6 


0100H 


00A5H 


LINE 




45 


0100H 


01BaH 


LINE it: 


]0 


010OH 


0AEH 


LINE 




^6 


0100H 


01C2H 


LINE ff: 


12 


P100H 


00BFH 


LINE 




47 


0100H 


0.1C8H 


LINE #: 


.13 


0100H 


0D0H 


LINE 




48 


0100H 


0.1D]H 


LINE #: 


14 


0100H 


00E7H 


LINE 




49 


0100H 


01D'?H 


LINE #: 


16 


0100H 


00F8H 


LINE 




5^ 


0100H 


01DAH 


LINE if: 


17 


0100H 


0130H 


LINE 




51 



P100H 


13eH 


LINE I: 


^2 


1 001! 


0142H 


LINE #: 


53 


010BF1 


014BH 


LINE #: 


54 


O100H 


015EH 


LINE (1: 


55 


O100H 


Pir,9H 


LINE il : 


5 6 


100H 


17AH 


LINE {f: 


57 


riflEK 


18 5H 


LINE #: 


58 


0100H 


018EH 


L IIvl E ft : 


=^3 


0100H 


019FH 


LINE «: 


6 


0100H 


01AAH 


LINE I: 


61 


0100H 


01B3H 


LINE H : 


62 






MODULE: 


FIN 


0100H 


023AH 


SYMBOL: 


ABC 


0100H 


0242H 


SYMBOL: 


DEF 


0100H 


0225H 


SYMBOL: 


FINDMX 


012AH 


009CH 


SYMBOL: 


MAX 


0100H 


024DH 


SYMBOL: 


XYZ 


0100H 


22 5H 


PUBLIC: 


FINDMX 






MODULE: 


SBCCO 


0100H 


0266H 


PUBLIC: 


CO 
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APPENDIX C 
PROGRAM LISTING FOR EXECUTION$VEHICLE MODULE WITH CODE EXPANSION 

PL/M-86 COMPILER EXECUTIONVEHICLE 

ISIS-II PL/M-8fi VI. COMPILATION OF MODULE EXECUTIONVEHICLE 

NO OBJECT MODULE REQUESTED 

COMPILER INVOKED BY: PLMOfi : F] : MATRIX . PLM DEBUG CODE NOOBJECT PR INT r ; F.l : MATRIX. XLS ) 



MATRIX MULTIPLICATION EXAMPLE PROGRAM 

PL/M-36 MAIN PROGRAM WHICH: 

A) INITIALIZES TWO INTEGER MATRICES 

B) MULTIPLIES THE TWO MATRICES AND STORES THE RESULT IN A 
THIRD MATRIX 

C} CALLS AN ASSEMBLY LANGUAGE PROCEDURE WHICH SEARCHES THE 
THIRD MATRIX FOR THE MAXIMUM VALUE 

D) CALLS A PL/M PROCEDURE WHICH CONVERTS THE MAXIMUM VALUE 
FROM INTEGER TO ASCI I 

E) CALLS A PROCEDURE WHICH OUTPUTS THE ASCII CHARACTERS ON 
THE SYSTEM CONSOLE 



EXECUTION$VEHTCLE: 



FrND$.'«lX - EXTERNAL ASSEMBLY LANGUAGE PROCEDURE WHICH SEARCHES 

MATRIX FOR THE LARGEST ABSOLUTE MAGNITUDE, 

PARAMETERS: 

MATRIXSADR - ADDRESS OF THE MATRIX TO BE SEARCHED 
ROWS - NUMBER OF ROWS IN THE MATRIX 
COLS - NUMBER OF COLUMNS IN THE MATRIX 



FIND$MX: PROCEDURE (MATRIXSPTR, 
DECLARE (ROWS, COLS) INTEGER; 
DECLARE MATRIXSPTR POINTER; 
END FIND$MX; 



ROWS, COLS) INTEGER EXTERNAL; 



/* BINSDECfASC - BINARY TO DECIMAL ASCII CONVERSION PROCEDURE 
PARAMETERS: 

VALUE - INTEGER VALUE TO BE CONVERTED TO ASCII 
CHAR."?ARRAY$ADR - ADDRESS OF G BYTE ARRAY WHERE ASCII 
STRING CONTAINING THE VALUE WILL BE STORED 
V 
BINSDECSASC: PROCEDURE (VALUE, CHARSARRAY$ADR) ; 

; STATEMENT ^ «5 







BINDECASC 


PROC NEAR 


0IB5 


55 


PUSH 


BP 


01B6 


8BEC 


MOV 


BP,SP 



DECLARE (VALUE, TEMP, I) INTEGER; 

DECLARE CHARSARRAY.'JADR POINTER; 

DECLARE (CHAR$ARRAY BASED CHAR$ARRAY$ADR) ((i) BYTE; 



IF VALUE < THEN 












; STATEMENT 5 


10 


01BR 817E0fi00fi0 


CMP 


rBP] .VALUE, 0H 




01BD 7C03 


JL 


$ + 5H 




01BF E91200 


JMP 


01 




DO; 








CHAR?ARRAY(0) = 


'- ' ; 


/* SIGN CHARACTER */ 








; STATEMENT # 


12 


01C2 8B5E04 


MCV 


BX, fBPl .CHARARRAYADR 




01C5 Cfi072D 


MOV 


CHARARRAYrBX] , 2DH 




TEMP = -VALUE; 












; STATEMENT * 


13 


riC8 8B4'=;06 


MOV 


AX, fBPl. VALUE 




01CB F7D8 


NEG 


AX 




CJCD 890600C0 


MOV 


TEMP, AX 




END; 












; STATEMENT # 


14 


01DJ E90D00 


JMP 


02 




^1: 








ELSE 








DO; 








CHAR$ARRAY(('") = 


' + ' ; 










; STATEMENT # 


16 


01D^ 8B5E0^ 


MOV 


BX, TBPl .CHARARRAYADR 




01D7 C6072B 


MOV 


CHARARRAYfBXl , ?BH 




TEMP = VALUE; 












; STATEMENT # 


17 


0]DA 8E4'^0(5 


MOV 


AX, TBPl .VALUE 




01DD 89Of>f00(^. 


MCV 


TEMP, AX 




END; 








P2: 








DO I = 5 TO .1 BY - 


■1 ; 










; STATEMENT f 


19 


riE] C70602000500 


MOV 


I,5M 




01E7 E90SrC 

1EA 8.1 0?^02P0FFFF 


JMP 


?5 




ADD 


I,0FFFFH 
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05: 






fiFe 


813E02000100 


CMP 


I, ]H 


Pipr. 


7D03 


JGE 


$+5H 


01F8 


E92600 


JMP 


P4 




CHARSARRAY (I) = 


UNSIGNfTEMP MOD 10) + 30H; 








; STATEMENT # 


01FB 


8B060000 


MOV . 


AX, TEMP 


0J.FF 


B90A00 


MOV 


CX,0AH 


02P2 


31D2 


XOR 


DX,DX 


0204 


F7F9 


IDIV 


CX 


0206 


P]C23000 


ADD 


DX,30H 


020A 


eB5E0'1 


MOV 


BX, [BPl .CHARARRAYADR 


020D 


8B360200 


MOV 


SI, I 


02J ] 


TEMP = TEMP/]0; 


MOV 


TBXl .CHARARRAYrsi],DL 



STATEMENT # 22 



; STATEMENT # 21 
/* ASCII CHARACTERS 30 THRU 39 HEX REPRESENT THE DIGITS THRU 9. THUS 
TO CONVERT AN INTEGER TO ASCII REPEATED DIVISIONS BY 10 AND ADDING 
THE REMAINDER TO 30 HEX WILL ACCOMPLISH THE CONVERSION */ 
0213 8B0(50000 MOV AX, TEMP 

0217 99 CWD 

0218 F7F9 IDIV CX 
021A 89060000 MOV TEMP, AX 

END; 
021E E9C9FF JMP 03 

END BIN$DEC$ASC; 

022.1 5D POP BP 

("2??. C2040r' RET 4H 

BIMDECASC ENDP 



/* CO - EXTERNAL PROCEDURE TO OUTPUT A CHARACTER TO THE SYSTEM CONSOLE, 
THIS PROCEDURE IS PART OF THE ISBC 9r-7 LIBRARY FOR CONSOLE 1/0 
PARAMETER: 

CHAR - ASCII CHARACTER TO BE OUTPUT ON THE CONSOLE 

* / 

CO: PROCEDURE ^CHAR) EXTERNAL; 

DECLARE CHAR BYTE; 

END CO; 



/* MATRIX DIMENSIONS 
DECLARE M LITERALLY ' 
DECLARE N LITERALLY ' 
DECLARE P LITERALLY ' 

/* THE THREE MATRICES ARE DECLARED AS ARRAYS OF STRUCTURES. X?ROW IS COMPOSED 
OF M STRUCTURES EACH OF WHICH IS COMPOSED OF N INTEGER ELEMENTS, THUS 
X$ROW MAY RE THOUGHT OF AS A M X N MATRIX, THE MATRIX WILL BE STORED AS 
A RCW-ORDER MATRIX WITH THE ELEMENTS OF EACH ROW STORED IN ADJACENT MEMORY 
LOCATIONS, YSROW IS DECLARED AS A N X P MATRIX AND ZfROW AS A N X P MATRIX 

DECLARE X$ROW(M) STRUCTURE (COL(N) INTEGER); 

DECLARE Y$ROW(N) STRUCTURE (COLrP) INTEGER); 

DECLARE Z$ROW(M) STRUCTURE (COLfP) INTEGER); 

DECLARE (I, J, K, MAX) INTEGER; 

DECLARE MAX$ASC$ARRAY (6) BYTE; 

DECLARE TEXTr*) BYTE DATA f'MAX VALUE = '); 

/* INITIALIZE X?^ROW SUCH THAT THE FIRST ROW IS SET EQUAL TO 0, THE SECOND 
ROW EOUAL TO 1, THE THIRD ROW EQUAL TO 2, ETC. */ 



DO 


I = TO fM-) ) 




; STATEMENT 


0002 


FA 


CLI 




00 3 


2E8E16000P 


MOV 


SS,CS:(?flSTACK?FRAME 


0008 


BC0800 


MOV 


SP,(aPSTACK$OFFSET 


000B 


8BEC 


MOV 


BP,SP 


000D 


16 


PUSH 


SS 


000E 


IF 


POP 


DS 


000F 


FB 


STI 




0010 


C70682000000 
P6: 


MOV 


I,0H 


0016 


813E82000500 


CMP 


I,5H 


001C 


7E03 


JLE 


$ + 5H 


001E 


E93C0C 


JMP 


07 




DO J = TO (N- 


-1); 


; STATEMENT 


0021 


C''C684000000 
P8: 


MOV 


J,0H 


0027 


813E84000400 


CMP 


J,/1H 


002D 


7E03 


JLE 


S + 5H 


002F 


E92200 


JMP 


P9 




X?ROW(I ) .COL 


J) = I; 


; STATEMENT 


0032 


«B06820f: 


MOV 


AX, I 


0036 


B90A00 


MOV 


CX, 0AH 


« 3 9 


F7E9 


IMUL 


CX 


00?B 


8B368400 


MOV 


, S T , J 


3F 


D1E6 


SHL 


sr , 1 


0^^! 


89C3 


MOV 


BX,AX 


0043 


8B0E8200 


MOV 


CX, I 


0/' 7 


89880/100 
END; 


MOV 


^BXl .XROwrsn ,CX 
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f.Ob] EQD3FF 

END; 

0^5^ filf"r,82Pl«0IP'0 
ei'.SA E9B9FF 



ADD J,]U 
,JMP PP 



ADD 
JMP 



STATEMENT <t 39 



STATEMENT # <! fi 



/*• INITIALIZE Y?ROW SUCH THAT THE FIRST COLUMN I 
SECOND COLUMN EQUAL TO 

DO I = p: TO (n--[ ) ; 



SET EQUAL TO C, , 



], AND THE TillRD COLUMN EQUAL TO -?.. 

41 



THE 



STATEMENT 



C/0 5D 


C70ri820000P0 
P10: 


MOV 


I,0H 


fiK(S3 


813E82000400 


CMP 


I,4H 


0P69 


7E03 


JLE 


$ + 5H 


flnfiB 


E940fl0 


JMP 


P]] 




DO J --= TO fP- 


-1) ; 




0(^6E 


C706840000P0 
@12: 


MOV 


J,0H 


ae^ia 


813E84O00200 


CMP 


J,2H 


mik 


7E03 


JLE 


$+5H 


007C 


E92600 


JMP 


313 




Y$ROW(I) .COL (J) = -J; 




007F 


PB068400 


MOV, 


AX, J 


0083 


F7D8 


MEG 


AX 


0085 


50 


PUSH 


AX 


008fi 


8B068200 


MOV 


AX, I 


008A 


B90600 


MOV 


CX,6H 


008D 


F7E9 


IMUL 


CX 


008F 


8B368400 


MOV 


SI, J 


0093 


DlEfi 


SHL 


SI,1 


2095 


89C3 


MOV 


BX,AX 


0097 


59 


POP 


CX 


0098 


89884000 
END; 


MOV 


fBXl.' 


009C 


810684000100 


ADD 


J,1H 


00A2 


E9CFFF 

P13; 


JMP 


PI? 


END; 






00A5 


810'S82000]0f 


ADD 


I,1H 


00AB 


E9B5FF 


JMP 


(Pin 



STATEMENT (t 4 2 



STATEMENT 



STATEMENT f 



Oil: 

/* PERFORM MATRIX MULTIPLICATION 
DO K = TO (P-] ) ; 



0AE 


C70(^8''i000000 
fil4: 


MOV 


K,0H 




0nB4 


813E«r,00020fi 


CMP 


K, 2H 




^CBA 


7E03 


JLE 


:r + 5n 




flPBC 


E9PC00 
DO I = TO (M 


JMP 
-1) ; 


PI 5 


; STATEMENT ^ ^7 


CCBF 


C70GP2000000 
P16: 


MOV 


I , CH 




('OCS 


8]3ER?O00500 


CMP 


I , '^•H 




0PCB 


7E0 3 


JLE 


r=!+5H 




00CD 


E972P0 


JMP 


a] 7 






Z$ROW(I) .COL(K) = f ; 


/* SET Z 


?ROW ELEMENT TO * / 










; STATEMENT ff 4S 


O0D0 


PB0^3200 


MOV 


AX, r 




00D4 


B90600 


MOV 


CX, -H 




00D7 


F7E9 


IMUL 


CX 




0D9 


8B368600 


MOV 


S I , K 




00DD 


D.lEfS 


SHL 


SI,1 




0flDF 


89C3 


MOV 


BX,AX 




00E1 


C7805E000000 


MOV 


[BXl .ZROWrsil ,0H 




DO J = TO 


(N-1); /* 


SUM THE 


PRODUCT OF X$ROW ROW TERM 
; STATEMENT # 4 9 


00E7 


C706e4000000 
018: 


MOV 


J,0H 




0eED 


813E84000400 


CMP 


J,4H 




00F3 


7E03 


JLE 


?+5H 




00F5 


E9'a] 00 


JMP 


(319 






Z$ROW(I) .COL(K) = 2 


$ROW(I) .COL(K) + ( X?;R0W(I) .COL(J) 










; STATEMENT #50 


00Fa 


BB068200 


MOV 


AX, I 




00FC 


B90A00 


MOV 


CX,0AH 




00FF 


F7E9 


IMUL 


CX 




0101 


8B368400 


MOV 


SI, J 




0105 


DlEfi 


SHL 


SI,1 




0107 


50 


PUSH 


AX 


; 1 


0108 


8B0G8400 


MOV 


AX, J 




010C 


B90fi00 


MOV 


CX,6H 




010F 


F7E9 


IMUL 


CX 




0111 


8B3E8600 


MOV 


DI,K 




0115 


D1E7 


SHL 


DI, 1 




0117 


89C3 


MOV 


BX,AX 




0119 


8B814000 


MOV 


AX,rBXl 


.YRQWrDJl 


011D 


5B 


POP 


BX 


; 1 


011E 


F7A80400 


IMUL 


FBX] .XROW[SI] 


0122 


50 


PUSH 


AX 


; 1 


0123 


OB068200 


MOV 


AX, I 




0127 


F7E9 


IMUL 


CX 




0129 


89C3 


-MOV 


BX,AX 





TERMS AND Y$ROW COLUMN TERMS */ 



Y$ROW(J) .COL(K) ); 
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P12B 


58 


POP 


AX 


1 




012C 


01815EP0 
END; 


ADD 


rexi .ZROw 


rDI],AX 
STATEMENT j 


? 51 


0130 


81068^000100 


ADD 


J,1H 






013-^ 


EgB-^FF 

PI 9: 
END; 


JMP 


P18 


STATEMENT ( 


* 52 


0139 


8]0'^P2O0010P 


ADD 


I , ] H 






013F 


E983FF 

P17: 


JMP 


ei6 






END; 


















STATEMENT j 


', 5 3 


0142 


810686000100 


ADD 


K, IH 






01^18 


E960FF 


JMP 


?] /I 







FINDSMX fPZ?ROW, M, P); /* 



FIND MAX VALUE OF Z$ROW 
; STATEMENT ff 5 ^ 



0I4B 


B85E00 


1 4 E 


50 


014F 


B8 0600 


0152 


50 


0153 


B80300 


0.1 5 6 


50 


0157 


E 8 00 



MOV 


AX, OFFSET (ZROW) 


PUSH 


AX 


; 1 


MOV 


AX, 6H 




PUSH 


AX 


; 2 


MOV 


AX,3H 




PUSH 


AX 


; 3 


CALL 


FINDMX 




MOV 


MAX, AX 





015A 89068800 

CALL BIN$DEC$ASC (MAX, PMAXSASCSARRAY ) ; /* CONVERT TO DECIMAL ASCII */ 

; STATEMENT #55 
015E FF368O00 PUSH MAX ; 1 
0162 B88A00 MOV AX, OFFSET (MAXASCARRAY) 

0165 50 PUSH AX ; 2 

0166 £84000 CALL BINDECASC 



DO I = TO (SIGNEDfSIZE (TEXT) ) 

0169 C70682000000 MOV I , 0H 

P20: 

016F P13E82000B00 CMP I , 0BH 

0175 7E03 JLE $+5H 

0177 E91400 JMP P21 

CALL CO (TEXT (I) ) ; 



1); /* OUTPUT HEADER TEXT 
; STATEMENT tt 56 



STATEMENT # 57 



V 



017A PB1E8200 


MOV 


BX,I 






017E FFB70000 


PUSH 


TEXTTBX] 


; 1 




0182 E80000 


CALL 


CO 






END; 






; STATEMENT # 


58 


0185 810682000100 


ADD 


I, ]H 






018B E9E1FF 


JMP 


P20 






P21: 










DO I = TO 5; /* 


OUTPUT 


ASCII MAX 


VALUE */ 

; STATEMENT # 


59 


018E C70682000000 


MOV 


I,0H 






P22: 










0194 813E82000500 


CMP 


T,5H 






019A 7E0 3 


JLE 


$ + 5H 






019C E91400 


JMP 


P2 3 






CALL CO(MAX$ASCi 


SARRAYU)); 












; STATEMENT ^ 


60 


019F 8B1E8200 


MOV 


BX,I 






01A3 FFB78A00 


PUSH 


MAXASCARRAY rex ] ; 1 




01A7 E80000 


CALL 


CO 






END; 






; STATEMENT # 


51 


01AA 810682000100 


ADD 


I,]H 






01B0 E9E1FF 


JMP 


P22 






P23: 











END EXECUTIONSVEHICLE; 



MODULE INFORMATION: 

CODE AREA SIZE = 0225H 5490 

CONSTANT AREA SIZE = 000CH 1 2D 

VARIABLE AREA SIZE = 0090H 144D 

MAXIMUM STACK SIZE = 0008H 8D 
137 LINES READ 
PROGRAM ERROR (S) 



; STATEMENT #62 



END OF PL/M-86 COMPILATION 
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I. INTRODUCTION 

As the microcomputer system found its way into 
more and more demanding applications the need 
became clear for a new and innovative solution to 
the old problem of providing timely response to 
real world events. This need was never clearer 
than in the field of communications where 
throughput and response time are the keys to 
success. The iSBC 544 Intelligent Communica- 
tions Controller (ICC) is the vanguard of a family 
of intelligent slave computers that provide a 
unique and powerful answer to the needs of the 
microcomputer user. 

This application note is intended to introduce the 
reader to the intelligent slave concept in general 
and the iSBC 544 board in particular. After a 
brief overview of the evolution of the concept and 
the features it provides, the hardware and 
software aspects of the controller are studied. 
Following this a summary of various system 
throughput tests is examined to evaluate the 
performance of the intelligent slave versus more 
traditional system architectures. We then study 
two example applications of the product and 
relate the earlier discussions to the real world. 
Finally, some system software is presented that 
handles all data transfer duties between master 
single board computers and intelligent slaves on 
the MULTIBUS system bus. More detailed 
information on many of the topics covered in this 
note can be found in the related publications 
listed in the front-piece. 



II. OVERVIEW 

Intelligent Slave Architecture 

Over the years, component technology has 
increased at a rapid pace going from discrete 
components (eg. transistors) to integrated circuits 
(eg. TTL devices) to programmable peripheral 
controllers (eg. Intel 8251 A Universal Synchro- 
nous/Asynchronous Receiver/Transmitter) to 
fully intelligent slave devices (eg. Intel 8041A 
Universal Peripheral Interface). At the system 
level the evolution followed a similar path using 
the increasing component technology to create 
more and more powerful system building blocks. 
The iSBC 508 I/O board used TTL logic to provide 
digital I/O expansion for iSBC computers. The 



iSBC 534 board took advantage of programmable 
LSI devices to provide a programmable commu- 
nications expansion board. Now, with the advent 
of the iSBC 544 Intelligent Communications 
Controller, a new level of system capability is 
made possible with the fully intelligent slave 
controller. 

The cornerstone of the intelligent slave architec- 
ture is the dual port memory. Through the use of 
this shared memory space, a fast and efficient 
protocol can be established to allow for coopera- 
tion between master and intelligent slave in 
solving the needs of the application system. In 
addition to the shared memory, the CPU on the 
intelligent slave also has some local RAM and 
local PROM storage for programs. By using this 
architecture the advantages of multiprocessing 
and Direct Memory Access (DMA) controllers are 
blended together. Unlike DMA controllers, the 
intelligent slave works totally within its own data 
space. Therefore, it is not affected by bus traffic 
nor does it add to this traffic. And, since the on- 
board CPU gets its instructions from local PROM 
instead of predefined hard-wired logic or micro- 
code, the user has total flexibility in defining the 
functions the intelligent slave will assume in the 
overall system. 

Although the contents of an intelligent slave 
make it look very similar to a single board 
computer, the assumption of the slave role pro- 
vides a distinct advantage. By performing duties 
for a master single board computer, the slave 
relieves the master of low-level processing duties 
and at the same time is itself relieved of system 
responsibilities. 

In order to position the iSBC 544 product and 
outline what features it brings to the application 
system it is necessary to define the functions 
involved with communicating data. The three 
main functional divisions are illustrated in Fig- 
ure 1. At the lowest level the physical intercon- 
nection is maintained. This level involves such 
standards as RS232C which defines the require- 
ments for transmitting bits from point to point. 

The data transmission level involves the transfer 
of bytes and/or blocks of data from devices to 
computers and from node to node in computer 
networks. The hardware dependent software 
such as interrupt service and device polling is 
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DATA PROCESSING 



DATA TRANSMISSION 



PHYSICAL INTERCONNECTION 



MASTER SINGLE BOARD COMPUTER 



DATA PROCESSING 



DATA TRANSMISSION 



MULTIBUS SYSTEM BUS 



Figure 1. Layering of Communication System Functions 

part of this level as are handlers for standard 
protocols such as SDLC, HDLC, Bisync and X.25 
or special purpose schemes and custom protocols. 

The highest level performs the actual processing 
of the data and calls upon the lower levels to move 
the data from place to place. The application 
software resides at this level as do some high level 
software functions such as program to program 
and process to process communications packages. 

Now that we have a map of system functions to 
guide us, it is possible to gain an understanding of 
the usefulness of a product like the iSBC 544 
Intelligent Communications Controller. If an 
iSBC 534 board (which contains four USART 
devices) was included to handle the expansion of 
serial I/O capacity the mapping of system 
functions would look like that shown in Figure 
2. The four USARTs on the board would handle 
the physical interconnection but due to the lack of 
intelligence on the board the master CPU would 
be burdened with all of the data transmission 
duties in addition to its real duty, data processing. 

When an iSBC 544 board is used in the system, 
the mapping of system functions is as shown in 
Figure 3. The physical interconnection is still 
handled by the USARTs on the board but now the 
on-board CPU can be programmed to assume the 
data transmission duties. With an intelligent 
slave in the system, the master CPU is freed to 
concentrate on the data processing functions and 
the end result is that each function in the system 
is handled in the most efficient manner possible. 



iSBC 534 BOARD 
USART 



I i 



PHYSICAL INTERCONNECTION 



Figure 2. l\/lapping of System Functions witii 
iSBC 534 Board 



MASTER SINGLE BOARD COMPUTER 



DATA PROCESSING 




MULTIBUS SYSTEM BUS 





ISBC 544 BOARD 




DATA TRANSMISSION 










1 1 


USART 


1 


1 1 
1 


PHYSICAL INTERCONNECTION 


1 
1 
1 
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1 





Figure 3. Mapping of System Functions with 
iSBC 544 Board 



1-114 



The iSBC 544 Board 

The iSBC 544 IntelHgent Communications 
Controller contains: 

• An Intel 8085A CPU operating at 2.76 MHz. 

• Sockets for up to 8K bytes of read only memory 
(user can choose Intel 2716, 2316E or 2732 
devices). 

• 16K bytes of dynamic, dual port Random 
Access Memory (RAM). 

• 256 bytes of static local RAM. 

• Four Intel 8251A USARTs with programmable 
baud rates. 

• Two Intel 8253 Programmable Interval Timers. 

• Intel 8155 parallel interface providing 22 
parallel I/O lines and one 14 bit interval 
timer. Various input and output lines are 
dedicated to provide an interface to a Bell 801 
or equivalent Automatic Call Unit (ACU). 

• 8259A Priority Interrupt Controller. 

III. HARDWARE CONSIDERATIONS 

This section of the application note will focus on 
the iSBC 544 hardware and will outline the 
features of the board and its uses. Appendix A 
contains simplified logic diagrams of the iSBC 
544 board which can be referenced in the follow- 
ing discussions. 

Two Mode Operation 

The iSBC 544 board is capable of operating in one 
of two modes; 1) intelligent slave and 2) stand- 
alone communications computer. The mode can 
either be set with a switch or it can be "toggled" 
via a software driven flip-flop on the board. In 
the intelligent slave mode the CPU on the iSBC 
544 board operates strictly within its on-board 
resources. Communications with 8-bit and 16-bit 
master single board computers is accomplished 
through the dual port memory. Since the on- 
board CPU executes code out of its local PROM 
program storage the system designer is free to 
define which functions the slave will assume in 
the system design. As discussed earlier, this 
could include all or part of the system data 
transmission duties or could involve application 
specific duties such as terminal format control, 
code conversion or terminal input editing. 



In the stand-alone mode, the logic on the board 
disables off board access to the dual port RAM 
and the bus buffers are used to allow the on-board 
CPU to access expansion memory and I/O on the 
MULTIBUS system bus. In this mode the iSBC 
544 board drives the bus busy (BUSY/) control 
line active disallowing any other bus master 
access to the bus. The stand-alone communica- 
tions computer is capable of performing all of the 
functions of the applications system. Referring 
once again to the diagram of the functions of a 
communication system, the stand-alone commu- 
nications computer, with or without system 
expansion, is responsible for all data transmis- 
sion and data processing functions. In small 
applications requiring multiple serial lines the 
stand-alone iSBC 544 controller is a perfect fit. 

In very special circumstances it is possible to 
share the system bus by toggling the mode set 
flip-flop between master and slave mode. Figure 4 



iSBC 544 
BOARD 



SET 

MASTER MODE 

FLIP/FLOP 



INITIALIZE 
204 



ISBC 204 
CONTROLLER 



RESET 

MASTER MODE 

FLIP/FLOP 



PERFORM 
ON-BOARD 
PROCESSING 



SET MASTER 

MODE 

FLIP/FLOP 




PERFORM 
OPERATION 



INTERRUPT 
TO SIGNAL 
COMPLETION 



CHECK 
STATUS 



Figure 4. iSBC 544 Controller Running iSBC 204 
Disk Controller 
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shows the flow chart for a routine (code in 
Appendix B) that makes use of the "software 
switch" to operate an iSBC 204 Diskette Control- 
ler. Using the iSBC 544 board in a system with 
DMA devices is not recommended except in cases 
where DMA accesses are short and relatively 
rare. The use of the GPU for the handling of other 
system devices could seriously degrade its 
performance as a communications controller. 
However, this capability could be extremely 
useful in a system such as a small message store 
and forward where the disk traffic is not heavy 
and including a CPU card just to handle the disk 
would be wasteful. Use of the "software switch" 
to share the bus with another iSBC CPU is not 
advised because of the amount of protocol that 
would be required to keep the CPUs from interfer- 
ing with each other on the bus. 

Dual Port RAM 

Figure 5 illustrates the dual port RAM memory 
array on the iSBC 544 card. A triple bus architec- 
ture is used to allow other MULTIBUS bus 
masters access to the RAM on the intelligent 
slave. Both the on-board CPU's bus and the 
MULTIBUS system bus are connected to the dual 





DUAL PORT 

CONTROL 

LOGIC 



port controller. From here the dual port bus is 
connected to the 16K of dynamic RAM memory. 
Memory transfer requests from either of the first 
two busses are handled by the dual port control 
logic with the on-board CPU being given priority 
if contention arises. The local CPU is favored so 
that it is not overly delayed in handling its time 
critical functions. 

The address mapping of the dual port memory on 
the iSBC 544 is diagrammed in Figure 6. The user 
can enable access from the MULTIBUS system 
bus to 0, 4K, 8K or all 16K of the RAM on each 
iSBC 544 board. The dual port control logic 
decodes the full 20-bit address and provides an 
8-bit data path to the bus. For these reasons the 
iSBC 544 board is compatible with 8080A, 8085A 
and 8086 based single board computers. The user 
can also select the block of addresses on the 
system bus to which the iSBC 544 RAM will 
respond. 
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Figure 5. Dual Port Control Logic 



Figure 6. Address Mapping on Dual Port RAM Block 
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When accessed by the on-board CPU, the dual 
port RAM always appears at 8000H. If the iSBC 
544 board is operating in the stand-alone compu- 
ter mode, the board is capable of generating the 
16-bit bus address supported by the 8085A CPU. 

Interrupt Structure 

The interrupt structure of the iSBC 544 controller 
is designed to handle the heavy load imposed by 
the inherent real-time nature of the communica- 
tions application. An 8259A Priority Interrupt 
Controller handles the four receiver and transmit- 
ter ready interrupts from the 8251A devices and 
provides vectored interrupts using one of many 
available priority schemes. In addition to the 
eight interrupt sources handled by the 8259 there 
are various others that can be connected directly 
to the vectored interrupt inputs on the 8085A 
(RST 5.5, 6.5, 7.5 and TRAP). One interrupt is 
generated by the dual port control logic whenever 
a byte is written into the base address of the dual 
port memory by an offboard CPU. This interrupt, 
the flag interrupt, is cleared automatically when 
the on-board CPU reads the byte and is useful 
when designing a master-slave protocol since it 
provides a unique interrupt to each slave in the 
system. 

If the 8251A devices are used to interface to 
modems the loss of carrier and ring indicator 
interrupts from all four channels need to be 
connected to 8085A interrupt request inputs. This 
is accomplished with four input OR gates tying 
the eight sources into RST 6.5. The ring indicator 
and carrier detect lines can also be monitored 
through a parallel I/O port. This port would be 
read in a polled system to determine status or 
could be used along with the OR-tied interrupts to 
determine which channel is sourcing the current 
interrupt. 

The remaining interrupt sources come from the 
extra timer/counters and from the MULTIBUS 
interrupt lines. In addition to receiving interrupts 
from the bus, the iSBC 544 board has the 
capability of generating MULTIBUS interrupts 
using the Serial Output Data (SOD) line on the 
8085A CPU. 

Modem and Autocall Interface 

The iSBC 544 controller uses 8251A and 8155 
devices for interface to modems and an autocall 



unit respectively. All of the necessary handsha- 
king signals concerned with the modem interface 
are connected to the 8251 A and the carrier detect 
and ring indicator signals, as previously men- 
tioned, can be connected to interrupt inputs. The 
8155 parallel ports are wired as shown in Figure 
7. All of the commonly used signals defined in the 
EIA RS-366 specification for interface to an 
autocall unit are provided. The software neces- 
sary for handling the ACU becomes a simple 
matter of responding to the ACU requests and 
sending out the BCD digits representing the 
number being dialed. In addition to the ACU 
interface, the 8155 monitors various signal states 
and provides software reset capabilities for the 
USARTs and some interrupts. 

IV. SOFTWARE CONSIDERATIONS 

Software for the iSBC 544 ICC falls into three 
main categories; device programming, master- 
slave protocols, and communications support. 
Each of these three topics is covered in the 
following section with the aim of defining the 
software requirements and functions of the iSBC 
544 board. 

Device Programming 

The main sources of the power and flexibility of 
this product are the programmable LSI devices on 
the board. The first duty of the on-board software 
is programming these devices to handle the 
specific task at hand. To start with, the 8251A 
USART can be programmed for synchronous or 
asynchronous operation. In synchronous mode 
the user specifies even, odd or no parity and either 
external or internal sync detect with one or two 
sync characters. In the asynchronous mode the 
programmer selects the parity, the character 
length (5, 6, 7 or 8 data bits), the framing control 
(1, V/z or 2 stop bits) and the baud rate scaling 
factor (input clock frequency divided by 1, 16 or 
64). 

The 8253 Programmable Interval Timers provide 
the receiver and transmitter clocks for the 
USARTs and, along with the 8251A baud rate 
scaling factor, are programmed by the software to 
provide the desired communications frequency. In 
addition, two additional 16 bit timers are left 
available to the applications programs to be used 
as event counters, real-time interrupts, etc. 
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Do 



Dg Dg D4 D3 D2 



OUTPUT , 
PORT ' 



INPUT 
PORT 



Do 



-NUMBER BIT NB1 (LSR): 1 = TRUE 
-NUMBER BIT NB2: 1 = TRUE 
-NUMBER BIT NB4: 1 = TRUE 

- NUMBER BIT NB8 (MSB): 1 = TRUE 

- USART RESET: 1 = TRUE 

- INTERRUPT RESET: 1 = TRUE 

- DIGIT PRESENT ON NUMBER BIT 
LINES: = TRUE 

-CALL REQUEST: = TRUE 



- RING INDICATOR, PORT 0: = TRUE 

- RING INDICATOR, PORT 1: = TRUE 

- RING INDICATOR, PORT 2: - TRUE 

- RING INDICATOR, PORT 3: = TRUE 
■ CARRIER DETECT, PORT 0: = TRUE 

• CARRIER DETECT, PORT 1: = TRUE 

• CARRIER DETECT, PORT 2: = TRUE 
CARRIER DETECT, PORT 3: = TRUE 



Figure 7. 8155 Pinout Definitions 



Do 



11 



PRESENT NEXT DIGIT: = TRUE 

. CALL COMPLETE, LINE TRANSFERRED TO MODEM: 
= TRUE 

- DATA LINE OCCUPIED: - TRUE 

ABANDON CALL & RETRY: --- TRUE 

FLAG INTERRUPT: 1 = TRUE 
■ POWER FAIL SENSED: 1 = TRUE 



The 8259A Priority Interrupt Controller is 
programmed to vector all interrupts through a 
jump table in memory. Also, the device provides 
software selectable priority schemes and an 
interrupt mask register for sophisticated interrupt 
management designs. 

Last, but not least, the 8155 Programmable 
Peripheral Interface provides various software 
controlled input and output ports as discussed in 
previous sections. One specific point to remember 
is that the power on state of the 8155 clamps the 
reset signal to the USARTs active and must be 
removed by programming the 8155 before com- 
munications can begin. 

Master- Slave Protocols 

If an application system is visualized at the 
highest level it appears to be a computer with 
various inputs and outputs as depicted in Figure 
8a. If this computer is broken down into a master 
CPU and one or more intelligent slaves, great 
increases in efficiency and system throughput 



can be realized by distributing the duties between 
the CPUs (Figure 8b). Once this split is per- 
formed, some well defined means of communica- 
tion between master and slaves needs to be 
defined so that the processes that execute on the 
different machines can cooperate. This means of 
communication takes the form of a protocol 
followed by both master and slave. 
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Figure 8a and 8b. System Software BJocIc Diagrams 
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The intelligent slave architecture was designed to 
simplify the development of the necessary 
protocol. The shared memory space in the dual 
port RAM provides a large communications 
buffer area where data and commands can be 
transferred using normal memory transfers. Data 
structures of any needed complexity can be built 
in this memory area and accessed by both master 
and slave. The flag interrupt can be used to 
provide a unique synchronization signal from a 
master to a given slave. In addition, the MULTI- 
BUS interrupt lines can be used to provide extra 
signals in both directions. As we shall see in the 
system software section, these basic tools can be 
utilized to design a general purpose data transfer 
mechanism which isolates the applications 
processes from the worries of protocols and 
s3ntichronization. 

Communications Support 

The previous software topics dealt mainly with 
the system overhead that must be handled by the 
communications processor. The larger and more 
important duty of the CPU is dealing with the 
application at hand — communications. 

When configured as an intelligent slave to some 
master iSBC CPU board, the iSBC 544 board 
works to offload the master of communications 
related functions and at the same time is itself 
relieved of a major share of the system overhead 
and can be tuned to provide the highest possible 
throughput. With this combination, more com- 
plex applications can be tackled where the 
number of lines and the line frequencies are 
greatly increased. Multiple systems can be 
employed to provide a network facility with the 
iSBC 544 board now handling the network 
protocol in addition to its other duties. The 
architecture of the iSBC 544 controller is designed 
to simplify the user's software development 
process. The board can be programmed to handle 
many possible data transmission functions from 
simple line protocols to terminal control to link 
protocols and all the way up to network protocols. 

In the stand-alone mode, the iSBC 544 board can 
assume total responsibility for the application. 
This can be done with on-board resources only or 
can include the support of offboard expansion like 
the iSBC 534 four channel serial controller. Appli- 



cations of the stand-alone controller could include 
cluster controllers, peripherals managers, line 
concentrators or any other small system. 

V. THROUGHPUT ANALYSIS 

This section of the application note deals with 
studies that have been done to quantify the 
performance of the iSBC 544 board in both the 
stand-alone and intelligent slave modes. After 
describing the various test configurations and 
assumptions the data will be presented in 
graphical form and analyzed. The graphical data 
can be found in Appendix C. 

Stand Alone Throughput 

The first two tests were run to determine the 
absolute best case throughput of the iSBC 544 
board configured as a stand-alone computer. Fig- 
ure 9a shows the iSBC 544 controller continuously 
outputting data from four buffers to the four 
USARTs. Figure 9b shows essentially the same 
setup with eight channels, four on the iSBC 544 
board and four on the iSBC 534 expansion 
card. In each configuration the 8251A was run in 
synchronous mode and the baud rate was incre- 
mented until the transmitter empty signal from 
the USARTs became active. Further increments 
of the baud rates would not have resulted in 
higher throughput since the CPU was already 
spending 100% of its available time responding to 
USART service requests. 

The maximum rate for the first configuration 
(iSBC 544 board only) was 32,311 baud per 
channel. When the iSBC 534 expansion board 
was added a rate of 12,186 baud per channel was 
achieved. The drop in baud rate was due to the 
extra processing required by the offboard logic 
(eg. reading 8259 interrupt controller on the iSBC 
534 board to determine which device is requesting 
service). 

It should be noted that the serial throughput tests 
were run with almost no overhead and no actual 
processing of the data involved. The reader is 
expected to apply information on the amount of 
overhead expected in each individual application. 
For instance, if the application code for a given 
system is expected to utilize approximately 40% of 
the available CPU time and we wish to run four 
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Figure 9a and 9b. Stand-Aione Throughput Configurations 
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full duplex channels in asynchronous mode the 
estimate of maximum baud rate would take the 
following form. 

32,331 baud per channel — 40% = 19,398.6 baud 

19,398.6 baud per channel synchronous x 10/8 
= 24,248.25 baud asynchronous 

24,248.25 baud per channel half duplex/2 = 
12,124.125 full duplex 

Therefore, the maximum standard baud rate 
would be 9600 baud per channel in full duplex 
asynchronous mode. 

Intelligent Slave Throughput 

The remaining four configurations were set up to 
determine the effectiveness of the intelligent slave 
in the overall system. The general system config- 
uration is illustrated in Figure 10. The boards 
surrounded by the box represent the systems 
under test. The disk controller and two iSBC 
80/20 single board computers were active on the 
bus to simulate the normal bus traffic load in an 
application system. Various bus duty cycles were 
created using the computers and the disk control- 
ler to perform tasks that resulted in fixed bus 
utilization. 



reflected the amount of bus time, master CPU 
time and slave CPU time left available to 
applications oriented tasks. In each case this 
percentage of time available was measured as the 
baud rate was stepped up so that a graph could be 
constructed showing time available as a function 
of transmission speed. 

CPU free time was measured using a counting 
program running in the background. After each 
USART interrupt the counter was started. As 
interrupts from other sources came in the count- 
ing was preempted and then resumed after 
servicing the interrupt. When the next USART 
interrupt occured, the counter contents were 
examined and if the value was lower than the 
stored value the current value became the stored 
value. After ten minutes the stored value was 
retrieved and used as an indicator of the worst 
case time available between interrupts. 

System bus utilization was measured using the 
circuit shown in Figure 11. The voltage measured 
by the digital voltmeter represented a time 
average of the voltage at the output of the flip- 
flop. A calibration chart was created using a 
pulse generator to simulate various duty cycles 
and then this chart was used to measure bus 
activity while the test was running. 
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Figure 10. General System Configuration for 
Throughput Testing 



Figure 11. Bus Free Time Measurement Circuit 



In each configuration a single full duplex channel 
was set up with the input provided by another 
CPU. Only those functions dealing with system 
overhead were included and the data measured 



Configuration 1 is shown in Figure 12. This 
system uses a typical method of communications 
expansion with the iSBC 80/30 single board 
computer handling the lines directly via the serial 
I/O ports on the iSBC 534 I/O controller board. 
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Fic|ure 12t System Throughput Test, Configuration 1 



Thp secppd configuration (Figure 13) illustrates 
the perfoiJmance of the traditional DMA control- 
ler approach, If the communications controller 
had pMA Ipgic instead of a dual port memory and 
transferred data directly into system memory the 
perfprniance would be as observed in this test. 

In configuration 3 (Figure 14) the iSBC 544 board 
wa^ used in the intelligent slave mode. This 



configuration differs from the second in that 
memory transfers involved only local memory 
and bus access was not required on a per 
character basis. 

The fourth and final configuration sought to 
identify the loading that additional intelligent 
slave controllers would impose on master CPU 
time and bus free time. Figure 15 shows the 



I 




Figure 13, System Throughput Test, Configuration 2 
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Figure 14. System Throughput Test, Configuration 3 
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Figure 15. System Throughput Test, Configuration 4 
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configuration with two iSBC 544 boards execut- 
ing identical programs. 

The graphical presentation of the results is split 
into two sections. The first three graphs (Graph 1 
through Graph 3) show the relationship between 
baud rates and the master CPU, system bus, and 
slave CPU utilization. All of these results are 
based upon tests with 30% induced bus traffic (i.e., 
the two iSBC 80/20 computers and the iSBC 204 
disk controller were active.) 

In graph 4, processor free time is graphed as a 
function of bus traffic. The processor in this case 
is the one actually involved with the data on a per 
character basis (i.e., iSBC 80/30 board in con- 
figuration 1, iSBC 80/30 board simulating DMA 
Controller in configuration 2, and iSBC 544 board 
in configuration 3). 

Finally, graph 5 illustrates the maximum attain- 
able baud rate for each configuration as the bus 
traffic is increased. 

All of the graphs identify the relative perfor- 
mance difference between the configurations. 
Absolute numbers are not presented due to the 
fact that the overhead imposed by the test 
software affects the CPU time being measured. 
Since the overhead applies equally to all config- 
urations, the relative performance indications are 
valid. 

Based upon the data presented, the DMA control- 
ler and intelligent slave use 3 times less CPU time 
than an I/O controller. Also, the iSBC 544 
intelligent slave generates 12% and 6% less bus 
traffic than the I/O controller and DMA control- 
ler respectively. Finally, the intelligent slave uses 
8% less slave CPU time than the DMA controller 
approach. 

The earlier discussion that dealt with the intelli- 
gent slave architecture pointed out that the 
distribution of intelligence would offload the 
master CPU so that it would retain sufficient 
processing power for the actual application, 
whatever that may be. In addition, it was stated 
that the assumption of the slave role would relieve 
the slave CPU of system overhead and at the 
same time reduce system bus traffic. All of these 
assumptions are supported by the results of the 
testing presented here. 



The second set of graphs identify the effects of 
bus traffic on the performance of the various 
components of the system. The main observation 
to be made in this sequence is the drop in CPU 
free times and maximum baud rates that occurs 
when the bus gets busy. This effect is observable 
in the communications processor free time when 
the iSBC 534 expansion board or the DMA 
controller configuration is used. No effect is 
evident in the configuration with an iSBC 544 
board. 

The cause of this effect is the amount of bus 
access required by each configuration to move the 
characters from the USART to or from the 
buffer. With an iSBC 534 board the master CPU 
receives an interrupt, polls the offboard 8259 
interrupt controller, reads in a character, stores it 
in system memory and sends an end of interrupt 
command to the offboard interrupt controller. 
When the iSBC 80/30 computer receives an 
interrupt all processing is performed onboard 
until a bus access is required to move the data 
byte from/to memory. In the case of the intelli- 
gent slave, all processing for a character is 
performed onboard. Thus, as the system bus 
becomes very fully utilized, the delays encounter- 
ed in receiving bus access by the first two 
configurations become significant. 

The fourth configuration, which was set up to test 
the effects of adding more intelligent slaves, 
shows that extra slaves cause no appreciable 
increase in system load. All of the data points for 
two slaves were identical to the points for one 
slave in graphs 1 through 5. 



VI. APPLICATION EXAMPLES 

A Distributed Control System 

The potential applications for a product like the 
iSBC 544 communications controller are almost 
unlimited and not restricted to the traditional 
Data Communications market. The first applica- 
tion example that is studied concerns industrial 
automation. Due to the fact that the system is 
distributed and requires a generalized network, 
the iSBC 544 board is a natural prospect to handle 
the communication links between the various 
nodes in the system. 
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Design Requirements 

The system to be designed is intended to provide 
the framework for a family of distributed control 
systems where the configurations and the objects 
to be controlled vary from system to system. Fig- 
ure 16 shows the general picture of the system. 




Figure 16. General Diagram of Distributed 
Control System 



The host is responsible for providing supervisory 
control and a high-level human interface. The 
system can be expanded as shown in Figure 17 
where the controllers attached to the host are 
replaced by intermediate nodes which contain 
controllers or other nodes. This process can be 
continued as far as is necessary to provide the 
needed number of controllers. Each controller in 
the diagram represents a localized closed loop 
control system that is tailored to the specific 
application. 

The following system requirements need to be met 
by the computer network: 

• The host CPU must have sufficient computa- 
tional power to handle the human interface, 
mass storage management, supervisory control 
calculations and network control. 

• The host CPU must not be overly burdened by 
low-level communications functions if it is to 
handle the other duties assigned to it. 

• Node controllers must be capable of handling 8 
medium speed lines and also modems and 
autocall units since the nodes or controllers 
attached may be remote. 
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Figure 17. Expanded Diagram of Distributed Control System 
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• The message transmission format must be 
independent of the configuration and end 
application. The nodes in the network must be 
capable of passing through messages with and 
without interpreting the contained data. 

• The system must be capable of auto-configura- 
tion (since the network configuration is tailored 
to the specific application, the host must be 
able to automatically determine the setup at 
power on). 

• Each node controller is responsible for verify- 
ing the integrity of the nodes attached. 

System Configuration 

Based upon the design criteria and the bench- 
mark information the chosen configuration uses 
an iSBC 86/12 Single Board Computer as the host 
with an iSBC 544 intelligent slave handling the 
communications load for the CPU. The USART 
on the CPU board will talk to the local terminal 
and an iSBC 206 Hard Disk Controller will be 
used to provide up to 40 Megabytes of mass 
storage capacity. 

The requirements for the node controllers point to 
an iSBC 544 board configured as a stand-alone 
communications computer with an iSBC 534 
board as expansion to provide the necessary 8 
lines. The throughput data indicated a raw 
throughput value of 12K baud on each channel. 
With the data rates expected being far below this, 
sufficient time will be left over for background 
functions. Thus, the software requirements for 
each node can all be met by the CPU on the iSBC 
544 board and the inclusion of an expansion 
board does not necessitate another iSBC compu- 
ter. 

A typical controller in the system would look like 
that shown in Figure 18. The iSBC CPU handles 
the local closed loop control, using parametric 
information sent from the host. This information 
would typically include setpoints, tolerances and 
alarm limits. The serial channel on the CPU will 
be used to maintain the link to the next level in 
the network. 

Preliminary Design 

The message format that the system uses is 
shown in Figure 19. When multiple nested levels 
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Figure 18. Typical Controller in Distributed System 



Figure 19. Message Format 
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Figure 20. Nested Level Address Information 

of nodes are used the data area of the message 
contains command and address information for 
the next level down (Figure 20). Interpretation of 
the commands in a given message is done on an 
individual basis except for a set of system-wide 
commands (eg. IDENTIFY is a system command 
meaning respond with your ID code). The flexi- 
bility afforded by this scheme can be extremely 
useful in a system where the end applications and 
configurations may be quite diverse (eg. a node 
controller that is processing a transmit command 
may be the only one that knows that it is sending 
to another node via a phone line and thus it 
interprets the contained data differently than 
another node would). The level of intelligence 
and the ease of programming of the iSBC 544 
board make this generalized transmission scheme 
possible. 



1-126 



The simplest means of auto-configuration re- 
quires each controller in the system to send an 
identity message to the nearest node. This node 
would know the logical address of the controller 
that sent the message and would attach this 
address to the message and retransmit it to the 
next level as illustrated in Figure 21. This process 
would be repeated until the host is reached and 
would contain, at this point, all necessary address 
information to reach the given controller. 



uses the map to determine the path to the node(s) 
responsible for the third floor and transmits the 
information through the network. 

Each node controller in the system has the added 
responsibility of verifying the integrity of all the 
nodes attached to it. This duty can be handled by 
periodic background commands issued from the 
host and propagated through the network. Each 
node is responsible for passing the command 
along and also polling the nodes attached to it 
and reporting back any error conditions. 



|ADDRESS|ADDRESS|iD] 




Summary 

Through the use of a powerful 16-bit iSBC Single 
Board Computer, various low-cost 8-bit iSBC 
CPUs and the iSBC 544 communications control- 
ler, a flexible and extensible distributed control 
system is easy to design. The dual nature of the 
iSBC 544 board provides both an intelligent front 
end to the host computer and a high-speed stand- 
along nodal concentrator. The ability to individ- 
ually customize the software on each controller 
provides for an easily expandable system design. 

Terminal Cluster Controller 

The second application example concerns itself 
with a terminal cluster controller. The system 
shown in Figure 22 uses a number of "dumb" 
terminals and makes them appear "intelligent" 
via a local microcomputer system. The local 
microcomputer interfaces with the operator and 
accesses a local data base to provide an inquiry 
and data entry service. When necessary, the local 
microcomputer is capable of calling the host via 
an autocall unit and exchanging information and 
updates to the data base. 



Figure 21. Auto Configuration 



The human interface on the host would provide a 
mapping mechanism to attach meaningful 
symbolic names to the various nodes in the 
system. This labeling, along with the application 
specific control algorithms, make it possible to 
say something like "lower the temperature on the 
third floor to 68°F". The host breaks this 
information down into setpoints and tolerances, 



Design Criteria 

The terminal cluster controller must meet the 
following criteria: 

• Support must be provided for from four to 
sixteen operator terminals all running at rates 
up to 2400 baud. 

® Line editing on input must be provided (delete 
characters, delete lines and pause output). 
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Figure 22. Terminal Cluster 



• Support for the terminals must be configurable 
in that certain stations may require different 
screen formats. 

• Support for an optional hard copy device must 
be allowed for. 

• A considerable amount of CPU free time must 
be available after the basic terminal facilities 
are included. This is due to the fact that the 
data base management software to be written 
to run on the master single board computer will 
be extensive. 

• Type ahead would be a desired feature since the 
processing on the master CPU after a line of 
input has been transmitted may cause a delay 
in responding and we would like to have the 
ability to continue entering input while waiting 
for the response. 

System Configuration 

The specific iSBC products needed to implement 
the system described are the iSBC 80/30 Single 
Board Computer with an iSBC 032 RAM Expan- 



sion Board, an iSBC 206 Hard Disk Controller 
and one to four iSBC 544 Intelligent Communica- 
tions Expansion boards. Intel's RMX/80 Real- 
Time Multitasking Executive will provide the 
basis for the software system and will include 
disk file support for the iSBC 206 controller 
through DFS/80. The full system configuration 
is illustrated in Figure 23. 
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Figure 23. Terminal Cluster Controller System 
Configuration 
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Preliminary Design 

The first design decision to be made involves the 
distribution of system functions. Due to the 
requirements for line-editing and type-ahead the 
software for processing characters input from the 
terminal keyboards will be somewhat lengthy. 
The standard terminal output handler will be 
very small but provisions for special screen 
format controls and/or hard copy devices must be 
allowed for. All of these requirements lead to the 
use of the iSBC 544 controller for all terminal 
functions. If the master CPU were burdened with 
all of these duties it would be unable to adequately 
perform its data base management functions. 
The fast CPU and 8K PROM capacity of the iSBC 
544 board will be more than adequate for the task 
at hand. 



The throughput tests indicate that the loading 
imposed by expanding the number of terminals 
(and therefore the number of iSBC 544 boards) 
will not adversely affect the performance of the 
rest of the system. Master CPU free time and bus 
traffic data for two intelligent slaves in the 
system were identical to the numbers for one 
slave. Thus, since the iSBC 80/30 single board 
computer and the MULTIBUS system bus can 
handle one iSBC 544 controller they can also 
handle the maximum of four controllers that may 
be required by this application. The only observ- 
able effect will be caused by the load the extra 
operators impose on the data base software itself. 



The software needed for the iSBC 544 board is 
now defined and divided into three major pieces; a 
terminal input handler, a terminal output handler 
and system software to support the handlers. 
Since the input and output handlers are invoked 
via USART interrupts, all that need be done is to 
write a single routine for each handler and have it 
talk to all of the devices on the board. This can be 
accomplished by vectoring the proper interrupts 
to the entry point of the routine and then polling 
the 8259A interrupt controller to determine which 
device needs servicing. 



The standard terminal input handler needs to 
read in the available character from the USART, 



check it to see if it is a special command character 
and, if not, store it into a buffer. If a command 
character is encountered, the handler will respond 
by performing the appropriate operation. 

The standard terminal output handler simply 
takes characters out of a buffer upon interrupt 
from the transmitter and sends them to the 
appropriate USART. If a different output handler 
needs to be substituted for a special terminal or a 
hard copy device, a new routine can be included 
by modifying the interrupt vector address in the 
8259A jump table. 

Since the RMX/80 Real-Time Multitasking 
Executive is being utilized on the master CPU it is 
desirable to create an RMX/80 handler for the 
iSBC 544 boards that accepts and processes 
normal terminal handler request messages. In 
this manner, application tasks that formerly 
communicated with the on-board USART via the 
RMX/80 Terminal Handler can be made to talk to 
one of the devices on the iSBC 544 board by 
simply changing the address of an exchange. The 
following paragraphs, as well as paragraphs in 
the section on system software, assume a know- 
ledge of the RMX/80 Real-Time Executive. This 
knowledge is not necessary to use the information 
contained in this application note. Interested 
readers are referred to the RMX/80 references 
listed in the front-piece. 

Since this application can have from one to four 
iSBC 544 boards the RMX/80 driver will need to 
be configurable. A set of tasks and exchanges 
will be created for each terminal in the system. 
One task and exchange pair will accept and 
process terminal input request messages while 
another pair will process terminal output re- 
quests. 

The remaining piece of software that is needed by 
this system will provide the means for getting 
commands and data between the master and 
intelligent slave. Since this is a common need in 
any system utilizing an intelligent slave we will 
develop a general purpose scheme that can be 
used by any application. In this manner, a 
routine such as the terminal input handler can be 
written without any concern for how it will get the 
data it is inputting to the master CPU; all it need 
do is call upon a standard routine to "transmit" 
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the data. With these thoughts in mind, the 
following section discusses the system software 
developed for master-intelligent slave communi- 
cation. After the discussion of the system soft- 
ware we will revisit the software for the second 
application as an example of the use of the data 
transfer routines. 

VII. SYSTEM SOFTWARE 

In the earlier discussion of master-slave protocols, 
the notion was presented of developing a general 
purpose data transfer scheme which would enable 
the applications routines on both the slave and 
master to operate without concerning themselves 
with protocols and synchronization. This scheme 
can be implemented by designing a set of 
primitive routines to handle the data transfer 
activities. Thus, Figure 8b is expanded as shown 
in Figure 24 and the applications processes now 
call upon the primitives to handle the communica- 
tions between the master and the slave. 

Data Transfer Primitives 

The basic mechanism used by this implementa- 
tion of the primitives is a wraparound queue as 
shown in Figure 25. Each 8251 A device has 
associated with it, in dual port memory, an input 
and an output queue each of which have a give 
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Figure 25. Wrap-around Queue Used by Data 
Transfer Primitives 

and a take pointer. The give pointer contains the 
address of the next location in the queue that is 
available for filling with data. The take pointer 
contains the address of the next byte in an output 
queue that has been filled and is available. A 
queue is empty when the give and take pointers 
are equal and it is full when the act of incre- 
menting the give pointer would make it equal to 
the take pointer. A wrap function is defined to 
increment a pointer such that an increment past 
the bottom of the queue ''wraps" the pointer 
around to the top of the queue. 
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Figure 24. System Software Diagram with Data Transfer Primitives 
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The primitives all make use of a queue informa- 
tion block located at the base address of the 
slave's dual port memory (Figure 26). All pointer 
information is base relative to accommodate the 
needs of the two CPUs who have different 
memory maps. The two flag bytes carry informa- 
tion for master-slave and slave-master synchron- 
ization signals. 



FLAG 


MASTER .► SLAVE 


FLAG 


SLAVE ^ MASTER 


GIVE (0) 



GIVE (7) 



BOTTOM (0) 



Figure 26. Queue Information Block 



The set of primitives provides two distinct 
methods of information transfer, line oriented 
and byte oriented. The line oriented primitives 
are listed in Table 1. Both get$line and send$line 
transfer information between the queues and 
buffers provided by the caller. The disadvantage 
of this scheme is the number of memory moves 
needed to transfer information. The advantages 
of the line oriented method are the relative 
efficiencies and the simplicity of the interface 
from the calling routine. 



The byte oriented primitives (Table 2) allow the 
calling routine to transfer data directly into and 
out of the queues. An example of the sequence for 
putting a character into a queue is illustrated in 
Figure 27. The routine servicing the receiver 
ready interrupt calls next$space to get a pointer to 
the next available slot in the queue and then uses 
this pointer to transfer the data byte directly into 
the queue. The new$line, xmit, open$line and 
receive primitives are necessary since the global 
give and take pointers cannot be modified until 
all manipulations on the affected section of the 
queue are complete. If the pointers were modified 
continuously the routine gathering the data from 
the other side may see invalid data. 

/* OPERATOR TYPES "L" */ 



PTR = NEXT$SPACE (QUEUE$NUMBER): 
VALUE = INPUT (USART$DATA$PORT); 
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Figure 27. Sequence for Putting Data Into Queue 



Table 1 
Line Oriented Primitives 



Primitive 


Arguments 


Usage 


send$line 
get$line 


Queue$token, buf$ptr, count 
Returns: overflow 

Queue$token, buf$ptr, count 
Returns: Actual 


Inserts count characters into queue from buffer 

If insufficient room available, overflow indicates how many would not fit 

Retrieves count characters from queue and puts them in buffer 
Actual indicates how many were actually moved 
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The remaining primitive routines deal with the 
general purpose needs of the application software 
with regard to interrupts, initialization and status 
checking. A full list of these support routines is 
contained in Table 3. 

There are many features of this implementation 
and a few of them should be pointed out at this 
time. By defining a general purpose set of 
primitive routines to handle the data transfer, the 
actual means by which the bytes are transferred 
between slave and master is not visible to the 
calling routine. If the actual mechanism used 
needs to be altered the change will not affect the 
application software as long as the same external 
interface is maintained. 



Another important feature of the primitive 
routines is the fact that they do not interpret the 
bytes that are sent to them. Due to this fact, the 
applications routines are free to send commands 
and parameters interspersed with the actual 
data. As an example, the terminal driver on an 
iSBC 544 board might perform format control 
based upon table information. The master appli- 
cations software could use the data transfer 
primitives to transmit commands and parameters 
to the slave to update its format control informa- 
tion. Another advantage of the fact that the data 
is not interpreted is that it allows the calling 
routine to determine what data gets sent along. 
For instance, a specific terminal might be 
transmitting ASCII code while the master 



Table 2 
Byte Oriented Primitives 



Primitive 


Arguments 


Usage 


new$line 

next$space 

back$space 

xmit 
open$line 

next$char 

receive 


Queue$token 
Returns: ptr 

Queue$token 
Returns: ptr 

Queue$token 
Returns: ptr 

Queue$token 
Returns: status 

Queue$token 
Returns: ptr 

Queue$token 
Returns: ptr 

Queue$token 
Returns: status 


Sets up a queue for byte oriented input. 
Ptr returned points to the first available byte. 

Increments the temporary give pointer to the next open space. 
Ptr returned either points to next byte or is zero specifying full queue. 

Decrements temporary give pointer. 

Ptr returned either points to byte or is unchanged indicating that the 

global give pointer was reached. 

Closes off a line entered via byte mode by updating global give ptr to 
equal temporary give ptr. StatusJs either "normal" or "null". 

Opens up a line for byte oriented output. 

Ptr returned either points to the next byte or is zero indicating an 

empty queue. 

Increments temporary take pointer. 

Ptr returned either points to next byte or is zero indicating an 

empty queue. 

Closes off a line retrieved in byte mode by updating global take 
pointer to equal temporary ptr. Status is either "normal" or "null". 



Tabie3 
Support Routines 



Primitive 


Arguments 


Usage 


get$status 


Queue$token 
Returns: status 


Returns status of queue. Possible values are "normal", "empty", 
"full" and "null". 


set$interrupt 


Queue$token, type 
Returns: status 


Generates a slave -* master or master -* slave interrupt. Type code 
Is illegal and codes 8H -* OFH are reserved for use by the primitives. 


set$handler 


Queue$token, handler$adr 
Returns: status 


Inserts address into vector table used for handling interrupts 
described above. 


s$init 


none 


Called from slave software to initialize. 


m$init 


none 


Called from master software to initialize. 
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software is expecting EBCDIC. The routine on 
the slave can very easily perform the necessary 
code conversion before stuffing the data into a 
queue. 

Sample Slave Softw^are 

Given the existence of the primitive routines the 
applications routines on the slave and master can 
deal with the specific duties of each device. The 
following paragraphs revisit the code from 
application example 2, first for the slave and then 
for the master. Full code listings for these 
programs can be found in Appendix D. 

The flowchart for the terminal input handler 
resident on the iSBC 544 board is shown in Figure 
28. Support is provided for deleting characters 
(Rubout), deleting lines (control-X), pausing and 
resuming output (control-S and control-Q) and 
terminating lines (escape and carriage return). 
The sections of code reproduced below use this 
terminal input handler to present an example of 
the use of the data transfer primitives to enter and 
edit a line of input from a terminal. The byte 
variable value is based on the address variable 
value$ptr which is assigned by calls to the 
primitives. The routine var$inp inputs and 
returns a data byte from an I/O port specified by 
a calling parameter. This is necessary since the 
particular US ART to be serviced is determined by 
reading the 8259A in-service register. 

/* case i; rubout; delete char */ 

do; 

neiA(.'6ptr = bact<4spaceC token); 
if newiptr=lengtht>ptr then 

dummy = echo(token+l,. Coel 1 ) , I ) ', 
e I se 
do; 

dunimy = echo(token+l, .(BS,SP/BSJ,3); 
Ptr = new!ljptr; 
count =count-l ; 
end; 



Following this, the byte input is checked to see if 
it is a control character and if so a block within a 
DO CASE statement is executed. As an example 
of one of these blocks, if the character input was a 
RUBOUT the code sequence below is executed. 
The back$space primitive is called and a tempo- 
rary pointer is returned to a location in the queue. 
A check is made to determine if the line was 
empty and, if so, a bell is echoed to signal the 
operator. If the pointer returned did not indicate 



an invalid RUBOUT the real pointer is assigned 
the value of the temporary pointer and a back- 
space, space, backspace is echoed to delete the 
previous character on the screen. Lastly, the 
character count for the current line is decre- 
mented. 

\/ALUe^PTR=iN)EXT$SPACe (QUEaE$NaM3li]R) ; 
V?\Lae = VAR$lLvIP(USARTi?DATA?PORT(NUM) ) ; 



RECEIVER READY 
INTERRUPT 




Figure 28. Flow Chart for Terminal Input Handler 
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In order to facilitate retrieval of the proper 
amount of information on the master side, the 
first byte of each message is defined to contain 
the number of characters in the message. Thus, 
when the master routine needs a line of input he 
uses the first byte as a count to retrieve the full 
line. The requirement for type-ahead is met by 
this mechanism since the number of lines in the 



queue at a given time is limited only by the length 
of the queue. When a full line of input is finished, 
the terminal input handler generates a slave to 
master interrupt to signal the master routine who 
may be waiting for this event. 

The flowchart for a minimal terminal output 
handler is shown in Figure 29. Upon receipt of a 
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Figure 29. Flow Chart for Terminal Output Handler 
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transmitter ready interrupt the output handler 
requests a character from the appropriate queue. 
If one is available it is output to the USART. If 
the queue is empty, the transmitter is disabled. 
Whenever the master routine sends a line into the 
queue it will generate an interrupt to signal the 
slave handler and the transmitter will be reen- 
abled. A line is opened via a call to open$line and 
it is kept open until 100 characters have been 
retrieved via calls to next$hyte. At this time the 
line is closed by a call to receive making the space 
available to be reused. After this, a new call to 
open$line starts the process over again. If the 
call to get$ status shows that the queue was full 
prior to the call to receive, an interrupt is sent to 
the master to reawaken any routine that may 
have been waiting for room in the queue to 
become available. 



Sample Master Softw^are 

The RMX/80 handler for the master single board 
computer that will communicate with the soft- 
ware on the iSBC 544 board is diagrammed in 
Figure 30. In addition, the RMX/80 message used 
to convey information to the handler is shown on 
the right. The full software diagram is illustrated 
in Figure 31. 

The input driver tasks execute a reentrant routine 
that services a request exchange that is specified 
in an initialization block that is unique to each of 
the input tasks. The necessary information is 
extracted from the request message and the 
get$line primitive is called upon to get a line of 
input from the queue. If the call to get$line for the 
length byte is unsuccessful the input task waits at 
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Figure 30. RMX/80 Handler for iSBC 544 Board 
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Figure 31. Master Software with RIVIX/SO Handler 



the appropriate signal exchange for an interrupt 
from the slave indicating that a line is now 
available. Once the request is fulfilled the actual 
and status fields are set and the message is sent to 
the response exchange specified by the user. 

The output handler performs in a manner very 
similar to the input handler. Upon receipt of a 
request message the handler attempts to transfer 
the characters from the user buffer to the 
appropriate queue. If the attempt is unsuccessful 
(ie. the queue has insufficient room available) the 
handler sends as many characters as will fit 
(count - overflow) and then waits for an interrupt 
from the slave indicating that room has been 
made available. This process is repeated until all 
of the data has been transmitted. As soon as the 
operation is complete the status field is cleared 
and the message is returned to the user specified 
response exchange. 

Since the number of iSBC 544 slaves in the 
system is variable as are the memory base 
address, device programming information and 



queue sizes, some means of providing configura- 
tion information to the RMX/80 handlers is 
needed. This information resides in the mem- 
ory $allocation$module. Public variables are 
declared in this module that are used by the 
RMX/80 tasks to determine how many devices 
(and therefore how many tasks need to be created) 
are in the system and where in the system address 
space their dual port RAM is located. In addition, 
queue sizes and device programming information 
are specified here. 

VIII. SUMMARY 

The intent of this application note has been to 
introduce the reader to the concept of the 
intelligent slave architecture and show the 
versatility of the first product based upon this 
architecture, the iSBC 544 Intelligent Communi- 
cations Controller. The hardware and software 
aspects of the device were studied and results of 
benchmark tests were presented and studied. 
Finally, two example applications were worked 
out using the product as both a stand-alone 
controller and as an intelligent slave. 
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The bottom line is that the iSBC 544 controller, of the fully programmabale intelligent slave to free 

due to the advanced architecture around which it the CPU for complicated processing duties, 
is designed, can be the means to the end for any 

application that requires communication. The I would like to extend my gratitude to Dave 

dual nature of the controller provides the full Jurasek for the work on the throughput testing 

power of a single board computer to the small and to Jack Tyler Inman for aid in the design of 

application while the large system can make use the system software. 
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APPENDIX A 
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Figure A-1. iSBC 544 Input/Output and Interrupt Block Diagram 
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APPENDIX A (Continued) 
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Figure A-2. iSBC 544 Memory Block Diagram 
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APPENDiXB 



A M 8 : Fl : DM A5 4 4 . MB i<:J 



ISIS-II 8081^/8085 MACRO ASSEMBLER, V3.0 



MODULE 



PAGE 



LOG oej 



LINE 



SOURCE STATEMENT 



0080 
00E4 
00E5 
0052 
40FF 
0004 
0001 
0002 

0000 



WJ2C 

002C 03E4 
00 2E DB81 

0030 AF 

0031 C43900 

0034 FB 

0035 C9 



0000 
0001 
0004 
0006 
0009 
000B 
000D 
000F 
0011 
0013 
0015 
0017 
0019 
001B 
001D 
0020 
0022 
0024 
0027 
0029 
002B 
002E 
0030 
0032 



F3 

31FFBF 

D3E4 

CD0000 

3E04 

D388 

3EFF 

D385 

3E40 

D385 

3E00 

D384 

3E00 

D384 

CD0000 

3E52 

D380 

CD0000 

3E01 

D381 

CD0000 

3E02 

D381 

D3E5 



$MOD85 

BASE 

MM SET 

MMRSET 

READ 

TCOUNT 

DMAMOD 

TADDR 

SADDR 



1 

2 

3 

4 

5 

6 

7 

3 

9 
10 

11 BUFFER: 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
32 
33 
34 
35 
36 
37 
38 
39 
40 
41 
42 
43 
44 
45 
46 
47 
48 
49 
50 
51 
52 
53 
54 
55 
56 
57 



EQU 

EQU 

EQU 

EQU 

EQU 

EQU 

EQU 

EQU 

DSEG 

DS 



80H 

0E4H 

0E5H 

52H 

40FFH 

04H 

1 

2 

128 



;BASE ADDRESS OF 204 

; MASTER MODE SET ADDRESS 

; MASTER MODE RESET ADDRESS 

;READ COMMAND CODE 

;TERMINAL COUNT AND DMA MODE 

;DMA MODE WORD 

; TRACK ADDRESS 

; SECTOR ADDRESS 

;SECTOR BUFFER 



'OF 



TEST OF CAPABILITiT FOR 544 TO SHARE MULTIBUS 
WITH OTHER MASTERS. ROUTINE PROGRAMS THE 204 
BOARD, INITIATES A READ TRANSFER, WAITS FOR 
AN INTERRUPT AND THEN TRAPS TO ICE85 BREAK- 
POINT AT 200. 



AS EG 

ORG 2CH 

OUT MMSET 

IN BASE+1 

XRA A 

CNZ ERRTRP 

EI 

RET 



;RST 5.5 ENTRY POINT 

;SET MASTER MODE 

;GET RESULT 

;SET FLAGS 

; NON-ZERO RESULT; ERROR TRAP 

;REENABLE 

; CONTINUE ON 



MAINLINE ROUTINE 

EXTRN INIT24 

EXTRN WAITC 

EXTRN WAITP 

CSEG 

DI 

LXI SP,0BFFFH 

OUT MMSET 

CALL INIT24 

MVI A, DMAMOD 

OUT 3ASE+8 

MVI A, LOW (TCOUNT) 

OUT 3ASE+5 

MVI A, HIGH (TCOUNT) 

OUT BASE+5 

MVI A,LOW(BUFFER) 

OUT BASE+4 

MVI A, HIGH (BUFFER) 

OUT BASE+4 

CALL WAITC 

MVI A, RE AD 

OUT BASE+0 

CALL WAITP 

MVI A, TADDR 

OUT BASE+1 

CALL WAITP 

MVI A, SADDR 

OUT 3ASE+1 

OUT MMRSET 



;204 INITIALIZATION ROUTINE 
;WAIT FOR 204 NOT BUSY ROUTINE 
;WAIT FOR 204 PARAMETER REGISTI 

DISABLE 

SET STACK POINTER 

SET MASTER MODE FLIP FLOP 

INITIALIZE 204 

SET DMA MODE 

SET CONTROL REGISTER 

OUTPUT LOW BYTE OF DMA ADDRESS 
OUTPUT HIGH BYTE OF DMA ADDRESS 

OUTPUT READ COMMAND 

TRACK ADDRESS 

SECTOR ADDRESS 

RESET MASTER MODE FLIP/FLOP 
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APPENDIX B (Continued) 



0034 FB 


58 




EI 


0035 76 


59 




HLT 


0036 C30002 


60 




JMP 




61 


ERRTRP: 




0039 76 


62 




HLT 




63 




END 



200H 



; ENABLE 

;AND HALT ; WAIT FOR INTEF 

;TRAP TO ICE85 BREAKPOINT AT 200 

; ERROR TRAP 

;FOR NOW 



PUBLIC SYMBOLS 



EXTERNAL SYMBOLS 

INIT24 E 0000 WAITC E 000£ 



WAITP E 0000 



USER SYMBOLS 

BASE A 0080 BUFFER D 0000 

READ A 00 52 SADDR A 00 02 



DMAMOD A 00 4 
TADDR A 0001 



ERRTRP C 00 39 
TCOUNT A 40 FF 



INIT24 E 0000 
WAITC E 00 00 



WAI 
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APPENDIX B (Continued) 



A M8 :F1: INIT2 4.M80 



ISIS-II 8080/8085 MACRO ASSEMBLER, v3.0 



MODULE PAGE 



LOG OBJ 



LINE 



SOURCE STATEMENT 



0080 
00E4 
00E5 
0069 
0035 
0010 
0018 
00FF 
00FF 
000D 
0008 
0008 
0009 
4000 
0004 
0.^0 
0020 
0010 



0000 
0001 
0003 
0004 
0006 
0008 
000A 
000C 
000D 
000F 
0012 
0014 
0016 
0019 
001B 
001D 
0020 
0022 
0024 
0027 
0029 
002B 
002C 
0030 
0032 



F3 

3E0E 

30 

D3E4 

D38F 

3E01 

D382 

AF 

D382 

GD9900 

3E35 

D380 

GDA100 

3E0D 

D381 

GDA100 

3E08 

D381 

CDA100 

3E08 

D381 

CDA100 

3E09 

D381 

GD9900 



1 
2 
3 
4 
5 
6 
7 
8 
9 
10 



$MOD85 

BASE 

MM SET 

MMRSET 

SEEK 

SPECFY 

BADTRl 

BADTR2 

NO 3 AD 

:taddr 

11 CHARS 

12 SETTLE 

13 STEP 

14 LOAD 

15 TGOUNT 

16 DMAMOD 

17 BUSY 

18 PARFUL 

19 RESFUL 
20 

21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
32 
33 
34 
35 
36 
37 
38 
39 
40 
41 
42 
43 
44 
45 
46 
47 
48 
49 
50 
51 
52 
53 
54 



INIT24: 



EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 



CSEG 
PUBLIC 
PUBLIC 
PUBLIC 

DI 

MVI 

SIM 

OUT 

OUT 

MVI 

OUT 

XRA 

OUT 

GALL 

MVI 

OUT 

CALL 

MVI 

OUT 

CALL 

MVI 

OUT 

CALL 

MVI 

OUT 

CALL 

MVI 

OUT 

CALL 



80H 

0E4H 

0E5H 

69H 

35H 

10H 

18H 

0FFH 

0FFH 

0DH 

08H 

08H 

09H 

4000H 

04H 

80H 

20H 

10H 



BASE ADDRESS OF 204 

MASTER MODE SET ADDRESS 

MASTER MODE RESET ADDRESS 

SEEK COMMAND 

"SPECIFY" COMMAND CODE 

SPECIFY BAD TRACKS SURFACE 1 

SPECIFY BAD TRACKS SURFACE 2 

NO BAD TRACKS 

CURRENT TRACK ADDRESS NOT KNOW^ 

SPECIFY DRIVE CHARACTERISTICS 

HEAD SETTLE TIME(SA800) 

STEP RATE 

HEAD LOAD TIME 

TERMINAL COUNT AND DMA MODE OF 

DMA MODE WORD 

204 BUSY MASK 

204 PARAMETER REGISTER FULL AS 

204 RESULT BYTE FULL MASK 



204 INITIALIZATION ROUTINE. RESETS 204 BOARD 
AND PERFORMS ALL OF THE NECESSARY INITIALIZATIO^ 
OF THE 8257 AND 8271. 



INIT24 

WAITC 

WAITP 



A,0EH 

MMSET 

SASE+15 

A,l 

BA3E+2 

A 

BASE+2 

WAITC 

A, SPECFY 

BASE+0 

WAITP 

A, CHARS 

BASE+1 

WAITP 

A, STEP 

3ASE+1 

WAITP 

A, SETTLE 

BASE+1 

WAITP 

A, LOAD 

3ASE+1 

WAITC 



ENTRY POINT 

WILL BE USED EXTERNALLY 



DISABLE 

ENABLE 5.5 INTERRUPT 

SET MASTER MODE FLIP FLOP 
RESET INTERFACE 
RESET 204 



WAIT TILL COMMAND WRITE VAL! 
OUTPUT "SPECIFY" COMMAND 



WAIT TILL PARAMETER WRITE V/ IE 
SPECIFYING DRIVE CHARACTERISTIC 



OUTPUT STEP RATE 



OUTPUT HEAD SETTLE TIME 



OUTPUT HEAD LOAD TIME 
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0035 


3E35 


0037 


D380 


0039 


CDA100 


003C 


3E10 


003E 


D381 


0040 


CDA100 


0043 


3EFF 


0045 


D381 


0047 


CDA100 


004A 


3EFF 


004C 


D381 


004E 


CDA100 


0051 


3EFF 


0053 


D381 


0055 


CD9900 


0058 


3E35 


005A 


D380 


005C 


CDA100 


005F 


3E13 


0061 


D381 


0063 


CDA100 


0066 


3EFF 


0068 


D381 


006A 


CDA100 


006D 


3EFF 


006F 


0381 


0071 


CDA100 


00-74 


3EFF 


0076 


D381 


0078 


CD9900 


007B 


3E69 


007D 


D380 


007F 


CDA100 


0082 


3E00 


0084 


D381 


0086 


D3E5 


0088 


FB 


0089 


76 


008A 


F3 


008B 


3E04 


008D 


0388 


008F 


3E00 


0091 


0385 


0093 


3E40 


0095 


0385 


0097 


FB 


0098 


C9 


0099 


DB80 


009B 


E680 


009D 


C29900 


00A0 


C9 


00A1 


DB80 


00A3 


E620 


00A5 


C2A100 


00A8 


C9 


PUBLIC 


SYMBOLS 


INIT24 


C 0000 



55 

56 

57 

58 

59 

S'd 

61 

62 

63 

64 

65 

66 

67 

68 

69 

70 

71 

72 

73 

74 

75 

76 

77 

78 

79 

80 

81 

82 

83 

84 

85 

86 

87 

88 

89 

90 

91 

92 

93 

94 

95 

96 

97 

98 

99 
100 
101 
102 
103 
104 

10 5 WAITC: 
106 
107 
108 
109 

110 WAITP: 
111 
112 
113 
114 



WAITC C 00 99 



MVI 

OUT 

CALL 

MVI 

OUT 

CALL 

MVI 

OUT 

CALL 

MVI 

OUT 

CALL 

MVI 

OUT 

CALL 

MVI 

OUT 

CALL 

MVI 

OUT 

CALL 

MVI 

OUT 

CALL 

MVI 

OUT 

CALL 

MVI 

OUT 

CALL 

MVI 

OUT 

CALL 

MVI 

OUT 

OUT 

EI 

HLT 

DI 

MVI 

OUT 

MVI 

OUT 

MVI 

OUT 

EI 

RET 



IN 
AN I 
JNZ 
RET 

IN 

ANI 

JNZ 

RET 

END 



A,3PECFY 

BASE+0 

WAITP 

A,BA0TR1 

3ASE+1 

WAITP 

A,N03A0 

3A3E+1 

WAITP 

A,NOBAO 

SASE+1 

WAITP 

A,CTADDR 

3ASE+1 

WAITC 

A,3PECFY 

3ASE+0 

WAITP 

A,BADTR2 

BASE+1 

WAITP 

A,NOBAO 

3ASE+1 

WAITP 

A,NOBAD 

BASE+1 

WAITP 

A,CTADOR 

BASE+1 

WAITC 

A, SEEK 

3ASE+0 

WAITP 

A,0 

3ASE+1 

MMRSET 



A,OMAMOD 

BASE+8 

A,LOW(TCOUNT) 

3ASE+5 

A,HIGH(TCOUNT) 

3ASE+5 



SPECIFY BAD TRACKS 

3A0 TRACKS FOR SURFACE 1 

FIRST TRACK 

SECOND BAD TRACK 

CURRENT TRACK ADDRESS (NOT i' *0V» 

SURFACE 2 
FIRST TRACK 



SECOND TRACK 

CURRENT TRACK ADDRESS (NOT I" 0^ 

SEEK TO TRACK 



GO TO SLEEP WHILE 204 DOES IT 

ENABLE INTERRUPTS 

SLEEP 

DISABLE 

SET DMA MODE 

SET CONTROL REGISTER 



RETURN 



WAITC AND WAITP ROUTINES 



BASE+0 

BUSY 

WAITC 



6ASE+0 
PARFUL 
WAITP 



;GET STATUS BYTE 

;BUSY? 

; YES, LOOP 

;N0, RETURN 

;GET STATUS REGISTER 
; PARAMETER BUFFER FULL? 
; YES, LOOP 
; NO, RET URN 



WAITP C 00A1 
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EXTERNAL SYMBOLS 



USER SYMBOLS 

BADTRl A 0010 BADTR2 A 0018 BASE A 00 80 

INIT24 C 0000 LOAD A 0009 MMR3ET A 00E5 

SEEK A 0069 SETTLE A 0008 SPECFY A 0035 



BUSY 


A 0080 


CHARS A 000D 


CT^ 


MM SET 


A 00E4 


NOBAD A 00 FF 


Af 


STEP 


A 0008 


TCOUNT A 400 


WAI 
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GIRAPH 1 

MASTER CPU FREE TIME 

VS BAUD RATE 



DMA CONTROLLER AND INTELLIGENT SLAVE 
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GRAPH 2 
BUS FREE TIME 
VS BAUD RATE 



INTELLIGENT SLAVE 




I/O CONTROLLER 
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GRAPH 3 

SLAVE CPU FREE TIME 

VS BAUD RATE 
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GRAPH 4 

COMMUNICATIONS PROCESSOR FREE TIME 

VS BUS TRAFFIC 

@ 9600 BAUD FULL DUPLEX 




50 60 

o/o MAX BUS TRAFFIC 
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GRAPH 5 

MAXIMUM BAUD RATE 

VS BUS TRAFFIC 



INTELLIGENT SLAVE 




% MAX BUS TRAFFIC 
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PL/M-80 COMPILER SLAVE MAINLINE ROUTINE PAGE 1 

ISI3-II PL/M-80 V3.1 COMPILATION OF MODULE MAINLINE 

OBJECT MODULE PLACED IN : Fl : MAINLN.OBJ 

COMPILER INVOKED BY: PLM80 : Fl iMAINLN . PLM PRINT (: F5 : MAINLN. LST) PAGEWIDTH (78) 



$title (' slave mainline routine') 
1 main$line: 

DO; 

/* 

Mainline routine. Sets up stack$ptr, calls s$init to init- 
ialize queues, initializes some of the hardware, sets up the 
initial flag interrupt handlers, and then halts with interru 
pts 

enabled allowing the rest of the system to operate totally 
in interrupt mode. 

V 

?nolist 

13 1 initial$handler: PROCEDURE EXTERNAL; 

14 2 END initial$handler; 

15 1 DECLARE 

command$word LITERALLY ' 41h ' , 
port$a$8155 LITERALLY '0e9h' , 
command$8155 LITERALLY '0e8h', 
mask$8259 LITERALLY '0e7h', 
icwl$8259 LITERALLY '0e6h', 
icw2$8259 LITERALLY '0e7h', 
ocw3$8259 LITERALLY •0e6h', 
read$isr LITERALLY '0bh', 
mask$word BYTE PUBLIC, 
port$a$value BYTE PUBLIC, 
Stat BYTE, 
i BYTE; 

16 1 output (icwl$8259)=0f6h; 

17 1 output (icw2$8259)=0fh; 

18 1 output (mask$8259) ,mask$word=0f fh; 

19 1 CALL s$init; 

/* set up 8259 for ISR reads */ 

20 1 output (ocw3$8259)=read$isr; 

output (command$8155) =command$word; 
output (port$a$8155) ,port$a$value=0c0h; 
DO i=0 TO 7; 

St a t=set$ handler (i , . initial$handler ) ; 
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21 


1 


22 


1 


23 


1 


24 


2 
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25 2 END; 

26 1 DO WHILE 1; 

27 2 HALT; 

28 2 ElMD,^ 

29 1 END main$line; 



MODULE INFORMATION: 

CODE AREA SIZE 
VARIABLE AREA SIZE 
MAXIMUM STACK SIZE 
72 LINES READ 
PROGRAM ERROR (S) 



004DH 


77D 


0004H 


4D 


0002H 


2D 



M52 
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P /M-80 COMPILER SLAVE APPLICATION LEVEL SIGNAL HANDLE PAGE 1 

ISIS-II PL/M-80 V3.1 COMPILATION OF MODULE INITIALHANDLER 

OBJECT MODULE PLACED IN : Fl : FINTRT.OBJ 

COMPILER INVOKED BY: PLM80 : Fl : FINTRT. PLM PRINT (: F5 : FINTRT. LST) PAGEWI DTH ( 78) 



$title (' slave application level signal handler'; 
initial$handler : 
DO; 



/* 



Fields application level flag interrupts from the 
master. If the tYpe=go$type the device attached to the queue 
specified is initialized with programming info sent into 
the queue by the master. If the type is data$available the 
specified transmitter is enabled unless a control$s pause 
is in effect. 



? no 1 i s t 

3 2 1 DECLARE 

no$pause LITERALLY '1', 
go$type LITERALLY '1', 
data$available LITERALLY '2', 
enable$xmit LITERALLY '1', 
reset LITERALLY '40h', 
timer$l$command$port LITERALLY '0dbh', 
timer$2$command$port LITERALLY '0dfh' 
mask$8259 LITERALLY •0e7h', 
mask$word BYTE EXTERNAL, 
mask (8) BYTE DATA ( 

0fch, 

0fch, 

0f3h, 

0f3h, 

0cfh, 

0cfh, 

03fh, 

03fh), 
transmitter$state (8) BYTE PUBLIC, 
type BYTE, 
token BYTE, 
i BYTE, 

prog?info (5) BYTE, 
actual ADDRESS, 

usart$command$port (8) BYTE EXTERNAL, 
usart$state (8J BYTE PUBLIC, 
lenqth$pointer (8) ADDRESS PUBLIC, 
pointer (8) ADDRESS PUBLIC, 
char$count (8) BYTE PUBLIC, 
timer$load$Dort (8) BYTE DATA ( 

0d8h, 
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33 


1 


34 


2 


35 
36 


2 
2 


37 
38 
39 


2 
2 
3 


40 
41 
4 2 


3 
4 
4 


43 


3 


44 


3 



45 


3 


46 


3 


47 


3 


48 


3 


49 


3 


50 


3 


51 


3 
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0d8h, 
0d9h, 
0d9h, 
0dah, 
0dah, 
0dchr 
0dch) ; 

initial$handler: PROCEDURE (code) PUBLIC? 

DECLARE code SliTTE; 



token=code AND 0fh; 
type=shr (code, 4 ) ; 

IF type=ao$tYpe THEiNl 
DO ; ' ' 

t r ansm i tte r$ St ate (token) =no$pa use; 
/* reset usart */ 

DO i=0 TO 3; 

CALL varout (usart$coinmand$port (token) ,0 ) ; 
Ei>lD; 

CALL varout (usart$command$port (token) , reset) ; 

actual=get$line(token, .prog$info,5) ; 

/* program the devices */ 

CALL varout (usart$coiTimand$port (token) ,prog$info (0) ) ; 
CALL varout (usart$command$port (token) ,usart$state (token) 
:=prog$info(l) ) ; 

IF token < 7 THEN 

CALL varout (timer$l$command$port,prog$info (2) ) ; 
ELSE 

CALL varout ( timer$2$comniand$port ,prog$inf o (2) ) ; 
CALL varout (timer$load$port (token) ,prog$info (3) ) ; 
CALL varout (timer$load$port (token) ,prog$info (4) ) ; 

/* open up the four input queues for data input */ 

52 3 length$pointer (token~l) =new$line (token-1) ? 

53 3 pointer (token-1) =next$space (token-1) ; 

54 3 char$count (token-l)=0; 

55 3 output (mask$8259) ,mask$word=mask$word AND mask (token) ; 

56 3 END; 

ELSE 

57 2 IF (type=data$available) AND (transmitter$state (token) =no$pa 

use) THEN 

58 2 DO; 

59 3 usart$state (token) =usart$state (token) OR enable$xmit; 

60 3 CALL varout (usart$command$port (token) ,usart$state (token) 

); 

61 3 END; 



1-154 



APPENDIX D (Continued) 



RETURN; 

63 2 END; 

64 1 END initial$handler; 
MODULE INFORMATION: 



CODE AREA SIZE 


= 0182H 


386D 


VARIABLE AREA SIZE 


= 0043H 


67D 


MAXIMUM STACK SIZE 


= 0004H 


4D 


154 LINES READ 






PROGRAM ERROR (S) 
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ISIS-II PL/M-8 V3.1 COMPILATION OF iVIODULE INPUTHANDLER 

OBJECT MODULE PLACED IN : Fl : INHDLR.OBJ 

COMPILER INVOKED BY: PLM80 : Fl : INHDLR.PLM PRINT ( :F5 rINHDLR. LST) PAGEWIDTH ( 78) 



$nointvector title('slave terminal input handler') 
1 input$handler : 

DO ; 

/* 

544 resident interrupt service routine. After receiver 
ready interrupt the 8259 In Service Register (ISR) is 
read to determine which device is requesting service. 
The character is read in and placed in the appropriate 
queue. A check is made for break characters and appropriate 
action is taken if any are found. When an endline character 
is encountered the length byte is filled in ( it was left 
vacant when the line was started) and thexmit primitive is 
called to update the global queue pointer to permit access 
to the line. At this time the master is signalled to signify 
that a new line is available for processing. 

V 

$nolist 

34 1 DECLARE 

control$x LITERALLY V18H', 

control$s LITERALLY '13H', 

control$a LITERALLY 'llH', 

rubout LITERALLY '7FH', 

escape LITERALLY ' 13H ' , 

CR LITERALLY ' 0OH ' , 

LF LITERALLY ' 0AH ' , 

BS LITERALLY '08H', 

SP LITERALLY "20H* , 

bell LITERALLY •07H', 

ptr LITERALLY ' pointer ( token) ' , 

length$ptr LITERALLY ' length$pointer (token) ' , 

count LITERALLY ' char $count ( token) ' , 

disable$xmit LITERALLY '0FEa', 

enable$xmit LITERALLY '01H', 

no$pause LITERALLY '1\ 

pause LITERALLY '0' , 

iine$available LITERALLY '1', 

ocw2$8259 LITERALLY ' 0E6a ' , 

ocw3$8259 LITERALLY '0E6H', 

EOI LITERALLY '20H'; 

35 1 DECLARE 

value$ptr ADDRESS, 

value BASED value$ptr BYTE, 

line$length BASED value$ptr BYTE, 

dummy ADDRESS, 

ISR BYTE, 

token BYTE, 
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Stat BYTE, 
new$ptr ADDRESS; 

36 1 DECLARE 

pointer (8) ADDRESS EXTERNAL, 
length$pointer (8) ADDRESS EXTERlSIAL, 
char$count (3) BYTE EXTERNAL, 
usart$state (8) BYTE EXTERNAL, 
usart$comniand$port (8) BYTE EXTERNAL, 
usart$data$port (8) BYTE EXTERNAL, 
transmitter$state (8) BYTE EXTERNAL; 

index: PROCEDURE (value) BYTE; 
DECLARE value BYTE; 

IF value=control$x THEN RETURN 0; 
IF value=rubout THEN RETURN 1; 
IF value=control$s THEN RETURN 2; 
IF value=control$q THEN RETURN 3; 
IF value=escape THEN RETURN 4; 
IF value=CR THEN RETURN 5; 
RETURN 6; 
END ; 

echo: PROCEDURE (token, buf$ptr ,nuin$char) ADDRESS; 

DECLARE (buf$ptr,num$ char, actual) ADDRESS, 
token BYTE; 

actual=send$line(token,buf $ptr ,num$char) ; 
usart$state (token) =usart$state (token) OR enable$xmit; 
CALL varout (usart$coinmand$port (token) ,usart$state (token) ) ; 
RETURN actual; 
END; 

60 1 delete$line: PROCEDURE; 

length$ptr=new$line (token) ; 
ptr=next$space (token) ; 
count=0 ; 

duinmY=echo(token+l, . ( '# ' ,CR,LF) ,3) ; 
RETURN; 
END; 

end$line: PROCEDURE; 

value$ptr=length$ptr ; 
line$length=count; 
ptr=next$space(token) ; 
stat=xmit (token) ; 
length$ptr=new$line(token) ; 
ptr=next$space(token) ; 
count=0; 

stat~set$s$interrupt (token, line$available) ; 
RETURN; 
END; 
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37 


1 


38 


2 


39 


2 


41 


2 


43 


2 


45 


2 


47 


2 


49 


2 


51 


2 


52 


2 


53 


1 


54 


2 


55 


2 


56 


2 


57 


2 


58 


2 


59 


2 



61 


2 


62 


2 


63 


2 


64 


2 


65 


2 


66 


2 


67 


1 


68 


2 


69 


2 


70 


2 


71 


2 


72 


2 


73 


2 


74 


2 


75 


2 


76 


2 


77 


2 
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78 1 in$hdlr: PROCEDURE INTERRUPT PUBLIC; 

79 2 ISR=input(ocw3$8259) ; 

80 2 token=6; 

81 2 again: 

ISR=shl(ISR,2) ; 

82 2 IF NOT carry THEN 

83 2 DO; 

84 3 IF token=0 THEN RETURN; /* no bits set */ 

ELSE 
86 3 00; 

37 4 token=token-2; 

88 4 GOTO aqain; 

89 4 END; 

90 3 END; 

91 2 value$ptr=ptr ; 

92 2 value=varinp (usart$data$port (token) ) AND 07fh; 

93 2 DO CASE index (value) ; 

/* case 0; control$x; delete line */ 

94 3 DO; 

95 4 CALL delete$line; 

96 4 END; 

/* case 1; rubout; delete char */ 

DO; 

new$ptr=back$space (token) ; 
IF new$ptr=length$ptr THEN 

dummy =echo (token+1 , . (bell) ,1) ; 
ELSE 

DO; 

dummy=echo (token+1, . (BS,SP,BS) ,3) ; 
ptr=new$ptr; 
count=count-l ; 
END; 
END; 

/* case 2; control$s; pause output */ 

DO; 

usart$state (token+1) =usart$state (token+1) AND disabl 
- e$xmit; 

109 4 CALL varout(usart$command$port (token+1) ,usart$state ( 

token+1)) ; 

110 4 transmitter$state (token+1) =pause ; 

111 4 END; 

/* case 3; control$g; resume output */ 

112 3 DO; 

113 4 usart$state(token+l)=usart$state (token+1) OR enable$ 
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97 


3 


98 


4 


99 


4 


100 


4 


101 


4 


102 


5 


103 


5 


104 


5 


105 


5 


106 


4 


107 


3 


108 


4 
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xmit; 
114 4 CALL varout (usart$command$port (token+1) ,usart$state ( 

token+1)) ; 

transmitter$state (token+1) =no$pause; 
Ei^D; 

/* case 4; escape; terminate line */ 
DO; 

dummy=echo (token+1,. ( ' # ' ,CR,LF) ,3) ; 

value=CR; 

count=count+l; 

CALL end$line; 
END; 

/* case 5; carriage return; terminate line */ 
DO; 

dummy^echo (token+1, . (CR,LF) ,2) ; 

count=count+l ; 

ptr=next$space (token) ; 

value$ptr=ptr ; 

v^lue=LF; 

count=count+l; 

CALL end$line; 
END; 

/* case 6; non-break character; stuff into queue */ 
DO; 

dummy=echo (token+1, ptr ,1) ; 

ptr=next$space (token) ; 

IF ptr=0 THEN CALL delete$line; /* full buffer */ 

ELSE count=count+l; 
END; 

END; /* of do case */ 
output (ocw3 $82 59) =EOI; 

RETURN; 

END ; 

END input$handler; 



MODULE INFORMATION: 

CODE AREA SIZE = 0398H 920D 
VARIABLE AREA SIZE = 0011H 17D 
MAXIMUM STACK SIZE = 0010H 16D 
255 LINES READ 
PROGRAM ERROR (S) 
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4 
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4 
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4 
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3 
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4 
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4 


126 


4 
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4 
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4 
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132 


3 
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P /M-Sa COMPILER SLAVE CHARACTER OUTPUT HANOLER PAQE 1 

ISIS-^II PL/M-80 V3.1 COMPILATION OF MODULE OUTPUTHA(SlDLER 

OBJECT MODULE PLACED IN : Fl :OUTHLR,OBJ 

COMPILER INVOKED BY; PLM80 :Fl :QUTHLR, PLM PRINT ( :F5:0UTHLR. LST) PAGEWIDTH (78) 



$nointvector title('slave character output handler') 
output$handl^r: 
DO; 



/* 



544 resident interrupt service routine. After transmitter 
ready interrupt, 8259 In Service Register (ISR) is read to 
determine which device is requesting service, A character 
is requested from the appropriate queue and, if available, 
is sent to the usart. If the queue is empty the transmitter 
is disabled pending a signal from the master when more 
characters are put into the queue. 



$nolist 

11 1 DECL/^RE 

ocw2$8259 LITERALLY '0E6H', 
ocw3$8259 LITERALLY •0E6H', 
disable$xmit LITERALLY '0FEH', 
true LITERALLY '0FFH' , 
false LITERALLY •00H', 
EOI LITERALLY ' 0A0H * ; 

12 1 DECLARE 

ISR BYTE, 
token BYTE, 
actual ADDRESS, 
value BYTE; 

13 1 DECLARE 

usart$state (8) BYTE EXTERNAL, 
usart$command$port (8) BYTE PUBLIC DATA( 

0D1H, 

0D1H, 

0D3H, 

0D3H, 

0D5H, 

0D5H, 

0D7H, 

0D7H) , 
usart$data$port (8) BYTE PUBLIC DATA( 

0D0H, 

0D0H, 

0D2H, 

0D2H, 

0D4H, 
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0D4H, 
0D6H, 
0D6H); 

14 1 out$hlr: PROCEDURE INTERRUPT 1 PUBHC; 

/* get active level number and use it to determine queue$toKen * 
- / ' 

15 2 ISR=input(ocw3$8259) ; 

16 2 tok3n=7; 

17 2 again: 

ISR=shl(ISR,l) ? 
IF NOT carry THEN 
DO; 

IF token=l THEN RETURN; /* no bits in ISR set */ 
ELSE 

DO; 

token=token-2; 
ISR=shl(ISR,l) ; 
GOTO again; 
END; 
END; 

actual=get$line (token, .value, 1) ; 
IF actual=0 THEN 

DO; /* empty queue. Disable transmitter */ 

usart$state (token) =usart$state (token) AND disabl 
e$xmit; 

32 3 CALL varout (usart$command$port (token) ,usart$stat 

e(token) ) ; 

33 3 END; 

ELSE 

CALL varout(usart$data$port (token) , value) ; 
output (ocw3$8259 ) =EOI ; 
RETURN; 
3ND; 
END output$handler; 



MODULE INFORMATION: 

CODE AREA SIZE = 00A4H 164D 
VARIABLE AREA SIZE = 0005H 5D 
MAXIMUM STACK SIZE = 000CH 12D 
102 LINES READ 
PROGRAM ERROR (S) 
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PL/M-80 COMPILER RMX/80-544 INITIALIZATION TASK PAGE 1 

ISIS-II PL/M-80 V3.1 COMPILATION OF MODULE INIT544 

OBJECT MODULE PLACED IN : F]. : INIT54 .OBJ 

COMPILER INVOKED BY: PLM80 : Fl : INIT54 . PLM PRINT ( :F5 : INIT54 . LST) PAGEWIDTH (78) 



$title( •rmx/80-544 initialization task') 
init$544: 
DO; 



/^ 



Task code for 544 driver initialization task. Info 

from application supplied memory allocation block 

is accessed to set up queues and transfer device programming 

info to the slave board (s) and create the required 

service handler tasks. 



$nolist 

56 1 input^driver: PROCEDURE EXTERNAL; 

57 2 END input$driver; 

58 1 output$driver: PROCEDURE EXTERNAL; 

59 2 END output$driver ; 

60 1 signal: PROCEDURE EXTERNAL; 

61 2 END signal; 

62 1 DECLARE 

stack$size LITERALLY '256', 
go$type LITERALLY '1'; 

63 1 DECLARE 

ptr ADDRESS, 

init$ table BASED ptr STRUCTURE ( 

base$adr ADDRESS, 

queue$token BYTE, 

prog$info (5) BYTE) , 
i BYTE, 
overflow ADDRESS, 
queue$init$table (1) STRUCTURE( 

base$adr ADDRESS, 

aueue$size (8) ADDRESS) EXTERNAL, 
initialization$table (1) BYTE EXTERNAL, 
Stat BYTE, 
num$devices BYTE EXTERNAL, 
num$boards BYTE EXTERNAL, 

service$exchange$table (1) ADDRESS EXTERNAL, 
signal$exchange$table (1) ADDRESS EXTERNAL, 
service$exchanqes (1) BYTE EXTERNAL, 
signal$exchanges (1) BYTE EXTERNAL, 
task$descriptors (1) BYTE EXTERNAL, 
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stacks (1) BYTE EXTERNAL, 
info$block (1) STRUCTaRE( 

base$adr ADDRESS, 

queue?token BYTE, 

index BYTE) EXTERNAL, 
rgactv ADDRESS EXTERNAL; 

64 1 DECLARE 

rom$input$std static$task$descriptor DATA( 
' input ' , 
. input$driver , 

0, /* stack will be assigned individually */ 
stack$size, 

200, 

0, /* tba */ 
0) , /* tba */ 
roin$output$std static$task$descr iptor DATA ( 
'output ' , 
.output$driver , 
0, 

stacksize, 
201, 
13, 

0)r 

input$hdlr$std s tat ic$ task $descr iptor , 
output $hdlr$std static$task$descr iptor ; 

65 1 init$xch: PROCEDURE (xch$ptr); 

/* initializes expanded interrupt exchanges */ 

66 2 DECLARE xch$ptr ADDRESS, 

xch BASED xch$ptr int$exchange$descr iptor ; 

67 2 xch. link=. xch. link; 

68 2 xch.type=int$type; 

69 2 xch.length=5; 

70 2 RETURN; 

71 2 END; 

72 1 init$54: PROCEDURE PUBLIC; 

DO i=0 TO num$boards-l; 

CALL m$init( .queue$init$table(i) ) ; 
END; 

CALL move (size (rom$input$std) , . rom$ input $std, .input$hdlr$std 
); 

CALL move (size (rom$output$std) , . rom$output$std, .output$hdlr$ 
std); 

ptr=. initialization$table; 

DO i=0 TO num$devices*2 BY 2; 
/* send pogramming info to slave */ 

overf low=send$ line (init$ table. base$adr ,init$ table, queue$ 
token, . init$table.prog$info,5) ; 

St a t=set$m$ interrupt (init$table.base$adr , init$table.queu 
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APPENDIX D (Continued) 

e$token,go$type) ; 
/* create service and signal exchanges */ 

CALL rqcxch (service$exchange$table (i) :=. service$exchange 
s+10*i) ; 

CALL rqcxch (service$exchange$table ( i+1) :=. service$exchan 
ges+10*(i+l)) ; 

CALL init$xch ( , signal$exchanges+15*i) ; 

CALL init$xch( . signal$exchanges+15* (i+1) ) ; 

CALL rqcxch (signal$exchange$table (i) :=. signal$exchanges+ 
- 15*i); 

87 3 CALL rqcxch (signal$exchanqe$table (i+1) :=. signal$exchange 

s+15*(i+l)); 

88 3 info$block(i) .base$adr, 
info$block (i+1) ,base$adr=init$table.base$adr; 
info$block (i) .queue$token=init$table.queue$token~l; 
in fo$ block (i+1) . queue $ token= ini t$ table. queue $ to ken; 
info$block(i) .index=i; 
info$block (i+1) . xndex=i+l; 

input $ hd Ir $ st d,sp=.stacks+stack$ si ze*i; 
output$hdlr$std. sp=. stacks+stack$size* (i+1) ; 
input$hdlr$std.exchange$address=. info$block (i) ; 
output$hdlr$std.exchange$address=. info$block (i+1) ; 
input? hdl r $std. task $ptr=. task $descriptors+20*i; 
output $hdl r $ st d. task$pt r =. task$d esc riptors+20* (i+1) ; 

CALL rqctsk (. input$hdlr$std) ; 
CALL rqctsk (.output$hdlr$std) ; 
ptr=Ptr+8; 
END; 

CALL rqsetv (.signal ,2) ; 
CALL rqelvl(2) ; 
CALL rqsusp(rqactv) ; 
EiSlD; /* of task */ 
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107 1 END init$544; 



MODULE INFORMATION: 

CODE AREA SIZE = 02C3H 707D 
VARIABLE AREA SIZE = 002AH 42D 
MAXIMUM STACK SIZE = 0006H 6D 
285 LINES READ 
PROGRAM ERROR (S) 
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P /M-80 COMPILER RMX/80-544 INITIALIZATION MODULE AlSlD PAGE 

ISIS-II PL/M-80 V3.1 COMPILATION OF MODULE INITMODULE 

OBJECT MODULE PLACED IN :F1:MAB.0BJ 

COMPILER INVOKED 3Y: PLM80 :Fl:MAB.PLM PRINT ( :F 5 : MAB . LST) PAGEWIOTH ( 7 8 ) 



$title ( ' rmx/80-544 initialization module and memory allocation b 

lock') 
init$module: 
DO; 

Initialization tables created and allocation of memory for 5 
44 

handler done here. 
V 

DECLARE 

number$of$devices LITERALLY '4', 
baud$rate$count$l LITERALLY '32' , 
baud$rate$count$h LITERALLY '00', 
usart$mode LITERALLY ' 4eh ' , 
usart.?cmd LITERALLY '27h', 
ctr$0$mode LITERALLY '36h', 
ctr$l$mode LITERALLY '76h', 
ctr$2$mode LITERALLY ' 0b6h ' , 
ctr$3$mode LITERALLY '36h', 

num$devices BYTE PUBLIC DATA (number$of $devices-l) , 
num$boards BYTE PUBLIC DATA ( 1 ) , 
service$exchange$table (8) ADDRESS PUBLIC, 
signal$exchanqe$table (8) ADDRESS PUBLIC, 
signal$type (8) BYTE PUBLIC, 
service$exchanges (80) BYTE PUBLIC, 
signal$exchanges (120) BYTE PUBLIC, 
task$descriptors (160) BYTE PUBLIC, 
stacks (2048) BYTE PUBLIC, 
info$block (32) BYTE PUBLIC, 
queue$init$table (1) STRUCTURE ( 
base$adr ADDRESS, 
queue$size (8) ADDRESS) PUBLIC DATA ( 

0e000h, 

256, 

1765, 

256, 

1765, 

256, 

1765, 

256, 

1765) , 
base$table (1) ADDRESS PUBLIC DATA ( 

0e000h) , 
initialization$table (number$of $devices) 3TRUCTURE( 
base$adr ADDRESS, 
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queue$token BYTE, 

prog$info (5) BYTE) PUBLIC DATA ( 

0e000h, 

1, 

usart^mode, 

usart$cmd, 

cti:$0$mode, 

baud$rate$count$l , 

baud$rate$count$h, 

0e000h, 

3, 

usart$mode, 

usart^cmd , 

ctr$l$mode, 

baud$rate$count$l, 

baud$rate$count$h , 

0e000hr 

5, 

usart$mode, 

usart$cmd, 

ctr$2$mode, 

baud$rate$count$l, 

baud $r ate $count$h, 

0e000h, 
7, 

usart$mode, 
usart$cmdf 
ctr$3$mode, 
baud$rate$count$l, 
baud$rate$count$h) ; 
END init$module; 



MODULE INFORMATION: 

CODE AREA SIZE = 0036H 54D 
VARIABLE AREA SIZE = 09B0H 2480D 
MAXIMUM STACK SIZE = 0000H 0D 
7 9 LINES READ 
PROGRAM ERROR (S) 
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P /M-80 COMPILER 3LAVE->MASTER INTERRUPT HANDLER PAGE 1 

ISIS-II PL/M-80 V3.1 COMPILATION OF MODULE 3IGWALHANDLER 

OBJECT MODULE PLACED IN : Fl : SIGNAL. OBJ 

COMPILER INVOKED BY: PLM80 : Fl : SIGNAL. PLM PRINT ( :F5 : SIGNAL. L3T) PAGEWIDTH (78) 



$nointvector title (' slave- >master interrupt handler') 
1 signal$handler : 

DO ; 

/* 

Fields all slave- >niaster signals (interrupts) and calls rqisn 
d 

with the proper signal exchange address. 
V 

$nolist 

26 1 DECLARE 

i BYTE, 

ptr ADDRESS, 

(flag BASED ptr) BYTE, 

num$boards BYTE EXTERNAL, 

num$devices BYTE EXTERNAL, 

signal$type (1) BYTE EXTERNAL, 

index BYTE, 

token BYTE, 

signal$exchange$table (1) ADDRESS EXTERNAL, 

base$table (1) ADDRESS EXTERNAL; 

27 1 signal: PROCEDURE INTERRUPT 2 PUBLIC; 

/* poll slave boards and find one generating interrupt */ 

i=0; 

next: 

ptr=base$table(i)+l; 
IF flag=0 THEN 
DO; 

i=i+l; 

IF i > num$boards THEN RETURN; /* erroneous signal * 

ELSE GOTO next; 
END; 

/* get queue token and use it to index into signal exchange tabl 
e */ 

37 2 token=(flag AND 0fh); 

38 2 index=4*i+token; 

/* if index is out of range don't attempt the isend */ 
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IF index <= num$devices THEN 
DO; 

CALL rqisnd (signal$exchange$table (index) ) ; 

s ignal$ type (index) =shr (flag ,4) ; 
END; 



ELSE 
44 2 CALL rqendi; 



/* zero flag to acknowledge interrupt */ 



45 2 flag=0; 

46 2 RETURN; 

47 2 END; 

48 1 END signal$handler; 

MODULE INFORMATION: 

CODE AREA SIZE = 008BH 139D 
VARIABLE AREA SIZE = 0005H 5D 
MAXIMUM STACK SIZE = 000AH 10D 
110 LINES READ 
PROGRAM ERROR (S) 
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P /M-80 COMPILER RMX/80-544 INPUT SERVICE HANDLER PAGE 

ISIS-II PL/M-80 V3.1 COMPILATION OF MODULE INPUTDRIVER 

OBJECT MODULE PLACED IN : Fl : INPUT. OBJ 

COMPILER It^VOKED BY: PLM80 : Fl : INPUT. PLM PRINT ( :F 5 : INPUT . LST) PAGEWIDTH ( 78 ) 



$title ( ' rmx/8l^-544 input service handler') 
input$driver : 
DO; 



/' 



rs 



Master resident task code. Monitors service exchange 

and fills input requests by retrieving characters from 

the proper queue (board$base and device info is passed 

via default exchange field) . By definition the jEirst byte 

of a line of input contains the length of that line. 

This figure is used to retrieve the exact number of characte 

available in a given line. 



$nolist 

27 1 DECLARE 

rgactv ADDRESS EXTERNAL, 
td BASED rqactv task$descr iptor , 
service$exchange$table (1) ADDRESS EXTERNAL, 
signal$exchange$table (1) ADDRESS EXTERNAL; 

28 1 input$driver: PROCEDURE REENTRANT PUBLIC; 

29 2 DECLARE 

service$exchange ADDRESS, 

board$base ADDRESS, 

queue$token BYTE, 

signal$exchange ADDRESS, 

msg$ptr ADDRESS, 

msg BASED msg$ptr th$msg, 

actual ADDRESS, 

dummy ADDRESS, 

info$block$ptr ADDRESS, 

info$block BASED inf o$block$ptr STRUCTURE ( 

base$adr ADDRESS, 

queued token BYTE, 

index BYTE) , 
num$char BYTE, 
Stat BYTE; 

/* get info out of default field */ 

30 2 info$block$ptr=td.exchange$address; /* default exchange fiel 

d */ 

31 2 service$exchange=service$exchange$table (info$block . index) ; 
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32 2 board$base=info$block .base$adr ; 

33 2 queue$token=inf o^block .queue$token; 

34 2 signal$exchange=signal$exchange$table (info$block. index) ; 

35 2 DO forever; 

/* wait for request message */ 

36 3 msg$ptr=rqwait (service$exchange,0) ; 

37 3 retry: 

/* try to get line count out of queue */ 

act ual=get$ line ( boar d$ base , queue? token, .nuin$char ,1) ; 

/* if unsuccessful wait for signal and try again */ 

IF actual = l4 THEN 
DO; 

dummy=rqwait (signal$exchange, 0) ; 

GOTO retry; 
END; 

/* if all okay get line */ 

43 3 actual=get$line(board$base,queue$token,msg.buffer$adr ,nu 

in$char ) ; 

44 3 nisg.actual=actual; 

45 3 msg . status=0 ; 

46 3 CALL rqsend (msg. resp$ex,msg$ptr ) ; 

47 3 END; /* of do forever */ 

48 2 END; /* of task */ 

49 1 END input$driver; 



MODULE INFORMATION: 

CODE AREA SIZE = 012CH 300D 
VARIABLE AREA SIZE = 0000H 0D 
MAXIMUM STACK SIZE = 0017H 23D 
171 LINES READ 
PROGRAM ERROR (S) 
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P /M-80 COMPILER RMX/80-544 OUTPUT SERVICE HANDLER PAGE 1 

ISIS-II PL/M-80 V3.1 COMPILATION OF MODULE OUTPUTDRIVER 

OBJECT MODULE PLACED IN : Fl : OUTPUT. OBJ 

COMPILER INVOKED Q1: PLM80 :Fl :OUTPUT. PLM PRINT ( :F5 lOUTPUT. LST) PAGEWIDTH ( 78) 



$title ( 'rmx/80-544 output service handler') 
1 output$driver: 
DO? 

/* 

Master resident task code. Monitors service exchange and 
fills output requests by stuffing characters into the approp 
riate 

queue. If insufficient room is available the task waits 
for 1 second and retries up to 100 times after which it 
signals a time out error. If the transmission completes 
successfully the slave is signalled to indicate that data' is 

available. 
V 

$nolist 

39 1 DECLARE 

data$available LITERALLY '2', 
time$out LITERALLY '1'; 

40 1 DECLARE 

rqactv ADDRESS EXTERNAL, 
(td BASED rqactv) task$descriptor , 
service$exchange$table (1) ADDRESS EXTERNAL, 
signal$exchange$table (1) ADDRESS EXTERNAL? 

41 1 output$driver: PROCEDURE REENTRANT PUBLIC? 

42 2 DECLARE 

service$exchanqe ADDRESS, 

signal$exchange ADDRESS, 

base$adr ADDRESS, 

queue$token BYTE, 

msg$ptr ADDRESS, 

msg BASED msg$ptr th$msg, 

tries$left ' BYTE, 

overflow ADDRESS, 

dummy ADDRESS, 

Stat BYTE, 

inf o$block$ptr ADDRESS , 

info$block BASED info$block$ptr STRUCTURE ( 

base$adr ADDRESS, 

queue$token BYTE, 

index BYTE) ? 
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/* initialize */ 

in fo$block$ptr=td.exchange$ address; 

service$exchange=service$exchange$table ( inf o$block .index) ; 
signal$exchange=signal$exchange$table(info$block. index) ; 
bas3$adr=info$block.base$adr ; 
qu eue$ to ken= in fo$ block .queue $ to ken; 

48 2 DO forever; 

/* wait for request message */ 

msg$ptr=rqwait (service$exchange,0) ; 
tries$left=100; 
retry: 

overf low= send $ line (base $ ad r , queue$ token, msg.buffer$adr ,m 
sg, count) ; 

IF overflow <> THEN 
DO; 

duinmy=r qwa it (signal $exchange, 20) ; 

tFies$left=tries$left-l; 

IF tries$left > THEN GOTO retry; 

ELSE 

DO; 

msg. Stat us= time $out; 
msg. actual=0 ; 
GOTO quit; 
END; 
END; 

msg. status=0 ; 
stat'=set$m$interrupt (base$adr ,queue$token,data$available 

) ? 

msg. actual=msg. count; 
quit: 

CALL rqsend (msg. resp$ex,msg$ptr) ; 
END; /* of do forever */ 

END; /* of task */ 

END output$driver; 



MODULE INFORMATION: 

CODE AREA SIZE = 0159H 345D 
VARIABLE AREA SIZE = 0000H 0D 
MAXIMUM STACK SIZE = 0019H 25D 
198 LINES READ 
PROGRAM ERROR (S) 
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A M8id :F1: CFG544. M80 PRINT ( : F4: CF^5 44,LST) PAGEWI DT.4 (7 8) MACROFILE 



ISIS-II 808fe)/8085 MACRO ASSEMBLER, V3.0 



CF3544 



PAGE 



LOG OBJ 



00-00 0800 



0000 
0000 



LINE 

1 

2 

3 

4 

5 

127 

128 

129 

130 

131 

132 

133 

134 

135 
136 
191 
246 
247 
248 
249 
253 
254 
255 
256 
264 
265 
266 
267 
274 



SOURCE STATEMENT 

NAME CFG544 

CSEG 

PUBLIC RQRATE 
RQRATE: DW 8 
$NOLIST 
$LIST 
$NOGEN 

NTASK SET 
NEXCH SET 

BUILD THE INITIAL TASK TABLE 

\ THIS TASK IS NECESSARY FOR THE 544 HANDLE 



-— / IT CREATES EVERYTHING PLSE IT NEEDS, 
STD INIT54,200,1,0 
STD LINECH, 64, 130,0 

ALLOCATE TASK DESCRIPTORS 

GENTO 

BUILD INITIAL EXCHANGE TABLE 

XCHADR RESPEX 

BUILD CREATE TABLE 

CRTAB 
END 



PUBLIC SYMBOLS 
RQCRTB C 0026 



RQRATE C 00 00 



EXTERNAL SYMBOLS 

INIT54 B 0000 LINECH E 0000 



USER SYMBOLS 
CRTAB +0000 
INTXCfl + 0000 
NTASK A 0002 
RQRATE C 00 00 
XCHADR +0002 



GENTD + 0000 
ITT C 0002 
PUBXCH + 0007 
STD + 0000 



RESPEX E 0000 



lET C 0024 
LINECH E 0000 
RESPEX E 0000 
TOBASE D 0108 



INIT54 E 0000 
NEXCH A 00 01 
RQCRTB C 00 26 
XCH + 0005 
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INTRODUCTION 

This report presents reliability test and supporting 
data for the Intel® SBC 80/10 Single Board Com- 
puter, a complete computer system on a single 
6.75-by-12 inch printed circuit board. The CPU, 
system clock, read/write memory, non-volatile 
read-only-memory, I/O ports and drivers, serial 
communications interface, bus control logic and 
drivers all reside on the board. 

A complete life testing program has been imple- 
mented to ascertain and quantify the rehabihty 
level of the Intel® SBC 80/10 Single Board Com- 
puter. This report presents a review of this pro- 
gram, including a discussion of the test configura- 
tion utiHzed, the system exerciser/diagnostic soft- 
ware used, the number of hours of testing per- 
formed, and the ambient test temperatures. High 
temperature testing was performed to accelerate 
product aging and to provide operational data on 
the reliability performance of the SBC 80/10 com- 
puter at elevated temperatures. 

Data gathered from this Ufe testing shows the 
SBC 80/10 to provide extremely reUable perform- 
ance. MTBF for the SBC 80/10 Single Board Com- 
puter is shown to be 91,739 hours (90% confi- 
dence) in continuous +25° C environments (average 
"room" temperature) and 25,006 hours (90% 
confidence) in continuous +55°C high temperature 
environments (maximum operating temperature 
specified for SBC 80 products). Data is also 



presented which shows that this life test data 
correlates well with actual field reliability data. 

A full description of Intel's complete component 
testing and quality assurance and board-level 
assembly, testing, and quality assurance procedures 
is also included in this report. This will provide an 
understanding of the production, testing, and qual- 
ity assurance procedures which all Intel® SBC 
80 Single Board Computer products undergo prior 
to shipment. This report is presented as a basis for 
reliability performance estimates for Intel's com- 
plete SBC 80 line of Single Board Computers and 
supporting expansion boards. 

SBC 80/10 COMPUTER DESCRIPTION 

The SBC 80/10 Single Board Computer is con- 
tained on a 6.75-by-12 inch printed circuit board. 
As Figure 1 shows, the CPU, system clock, read/ 
write memory, non-volatile read-only-memory, I/O 
ports and drivers, serial communications interface, 
bus control logic and drivers all reside on the 
board. Intel n-channel MOS LSI technology and 
bipolar TTL are the basis for the feasibiUty of such 
a full computer on a single PC board. Such a single 
board approach is inherently more reliable than 
traditional multiboard implementations through 
minimization of inter-board connectors. 

The heart of the SBC 80/10 Single Board Com- 
puter is the Intel® 8080A CPU which contains six 
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1. Interrupts originating from the Programmable Communications Interface and Programmable Peripheral Interface are jumper selectable. 

Figure 1. SBC 80/10 Block Diagram 
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8-bit, general-purpose registers and an accumulator. 
Complete reliability data on the 8080A micro- 
processor is contained in Intel Reliability Report 
RR-10. 1024 bytes of re ad /write storage are pro- 
vided by eight Intel low-power static RAMs. In 
addition to read /write memory, four sockets are 
provided to install four Intel 8708 1024 X 8 non- 
volatile, erasable and reprogrammable read-only- 
memories. The Intel 8708 EPROM has been shown 
to be an extremely reliable Read-Only-Memory 
(see Intel Reliability Report RR-12 for complete 
details). 

Two Intel 8255 Programmable Peripheral Interface 
devices supply 48 parallel I/O lines. These lines are 
routed to sockets on the board which are used to 
buffer lines programmed as outputs with TTL 
drivers or to terminate lines programmed as inputs 
with SBC 901 or SBC 902 resistor terminator 
packs. 

For serial communication, an Intel 8251 Universal 
Synchronous/Asynchronous Receiver/Transmitter 
(US ART) is contained on the SBC 80/10 com- 
puter. Additional circuitry provides jumper-select- 
able teletypewriter (20 mA current loop) or 
RS232C compatible interfaces for the USART. 

For further information on detailed operation of 
the SBC 80/10 computer, consult the Intel SBC 
80/10 Single Board Computer Hardware Refer- 
ence Manual. 



reliable and transferred to systems level manufac- 
turing, it is imperative that complete process con- 
trols are in effect to assure the continuation of 
high quality. Intel's component QA flow centers 
around a series of acceptance gates between 
process entities (see Figure 2) and detailed inspec- 
tion within the processing areas at critical points. 
For example, in wafer processing, furnaces are 
routinely monitored for contamination through 
the use of capacitance voltage measurements on 
test chips. Also, electrical tests such as breakdown 
strength measurements are performed on test 
patterns on each wafer. Routine high magnification 
scanning electron microscope examinations at 
critical process steps also provide important 
process control feedback. A final QA acceptance is 
performed on all lots prior to shipment to assem- 
bly locations. Table I details the Intel component 
QA acceptance gates within the assembly flow and 
identifies the appropriate method employed per 
MIL-STD-883. During the test and finishing opera- 
tion, QA maintains standards, test tape and calibra- 
tion control of all production equipment. Final QA 
inspection is performed after the mark and pack 
operation. 



Table I 
COMPONENT ASSEMBLY FLOW 



SINGLE BOARD COMPUTER QUALITY 
ASSURANCE 

The reliabihty of a board level product like the 
Intel® SBC 80/10 Single Board Computer is a 
function of the quality of components used on the 
board, care in board design and fabrication, and 
the extent of testing performed on the product 
before shipment. An examination of each of these 
functions will provide an understanding of the 
Intel quality assurance program for microcomputer 
system products. 

Component Quality Assurance 

Standard Intel® component quality assurance 
processing and 100% screening are apphed to all 
Intel components used on the SBC 80/10 com- 
puter before they are assembled on the board. 
Once a component device has been quahfied as 



OPERATION 


MIL-STD-883 
METHOD 


Piece Part Inspections 




Scribe and Break 




QA Acceptance 


2010. IB 


2nd Optical Inspection 


2010.1B 


Lead Bond 




QA Acceptance 


2010.1B 


3rd Optical Inspection 


2010.1B 


Seal 




Temperature Cycle 


1010(C) 


QA Acceptance 


1014(B) 


Fine Leak 


1014 (A) 




(10''^atmcc/sec) 


QA Acceptance 


1014(C) 


Gross Leak 


1014(C) 


QA Acceptance 


2009 


Final Visual 


2009 
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Figure 2. Component QA Flow Diagram 

Board Assembly 

Figure 3 shows the stringent cycle of inspection 
and testing each board undergoes before being 
shipped to the customer. After bare board manu- 
facture, boards are inspected for raw board quaHty 
conformance (i.e., hole registration, drilling, lami- 
nate integrity, artwork registration, etc.). Selected 
samples are sectioned and microscopically analyzed 
for comphance to specification. 



Components for an assembly "kit" are then pulled 
together and readied for the assembly operation. 
Visual inspection of each kit of components is then 
conducted. The kit is assembled onto the bare 
board and the assembled parts of the board are 
inspected prior to wave solder for proper location 
and after wave solder for soldering defects. Final 
assembly inspection insures the boards are ready 
for test. 

Board Production Testing 

Manufacturing testing, though not a part of reha- 
bility testing per se, is very effective in ehminating 
"infant mortahty" failures. These types of failures, 
by their nature, occur in the early Ufe of a product 
(see page 5). Each SBC 80/10 Single Board Com- 
puter is pre-baked at 80° C prior to any testing. 
Figure 4 shows some of the ovens utilized in this 
process. The boards are allowed to cool and then 
exhaustively tested on a Teradyne LI 25 Digital 
Diagnostic Tester. Use of a special "bed of nails" 
vacuum test fixture insures that all critical board 
test points may be accessed by the test system. 
Figure 5 shows the test fixture for the SBC 80/10 
computer, and Figure 6 shows one of the Teradyne 
test systems used in Intel® microcomputer board- 
level testing. Failed components are replaced, and 
the boards are retested on the Teradyne test sys- 
tem. 



QA ACCEPTANCE 
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C 
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Figure 3. Board Manufacture and Test Flow/Screening 




Figure 4. Ovens Utilized for Board Pre-Bake 
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When the boards have passed this thorough testing, 
they are then "system tested" to guarantee Intel® 
MULTIBUS'^'^ interface integrity. This consists of 
instaUing a set of Monitor and diagnostic program 
memory EPROMs into the four SBG 80/10 
EPROM sockets, applying all necessary voltages, 
and monitoring the SBC 80/10 computer's per- 
formance with a teletypewriter. The board per- 
forms all of the functions as described later in the 
reliability test section. After test, the boards are 
inspected for possible test damage. Boards passing 
this final screen are then released by Intel Quality 




Figure 5. SBC 80/10 Single Board Computer Test 
Fixture 




Assurance to Intel's standard product warehouse. 
Each product shipped is also subject to an audit. 
This audit consists of a complete review of docu- 
mentation, test, functional performance workman- 
ship, and handling. 

THE SBC 80/10 RELIABILITY TEST 

In order to establish reliability data for the SBC 
80/10 Single Board Computer, an extensive Hfe 
test program has been implemented. Twenty-one 
SBC 80/10 computers have been tested under vari- 
ous operating conditions. The various aspects of 
this program are discussed below. 

Reliability Test 

The test program used to exercise each SBC 80/10 
computer during Ufe testing was a modified version 
of the normal systems test, monitor, and diagnostic 
exerciser programs that each unit must pass prior 
to shipment. Figure 7 illustrates the hardware con- 
figuration of the test. Four Intel® 8708 EPROMs 
containing the monitor/diagnostic exerciser were 
installed in each SBC 80/10 computer to exercise 
virtually all of its functions. 




EQUIPMENT USED: 




Power Supplies: 
Power One 
Lambda 


G5-35/OUP 
LXS-D5-0V 


Test Equipment: 
Fluke 
Fluke 
Delta Design 


800A 
2240A 
6300/6400 


Communication: 




Teletype 
Centronics 


Model 33 
306C 



Figure 6. A Teradyne Test System Utilized in SBC 80 
Board Testing 



Figure 7. Life Test Configuration 
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The monitor program was a basic conditioning and 
communicative program. Among other things, it 
conditioned each SBC 80/10 computer to commu- 
nicate with a teletypewriter, allowed the operator 
to display and/or change the contents of RAM 
memory locations and direct the program counter 
to any designated memory location to begin 
processing instructions. The monitor program 
occupied the first IK of memory and started 
processing at location OOOOH. 

The diagnostic exerciser program, starting address 
0400H, is arranged into two major sections: the 
CPU/memory Test and the I/O Test. The Appendix 
provides a flowchart of this reliability test program. 

CPU/Memory Test 

The test program first sets aside sections of RAM 
memory to be used as temporary storage needed 
in later processing. It then begins executing the 
instruction set of the 8080A CPU, starting with 
conditional jumps, adds, subtracts, and compare 
instructions. Six sequential conditional call and 
return instructions are executed with combinations 
of register manipulations. All registers are checked 
for proper incrementing, decrementing, and com- 
paring. Different combinations of register com- 
pares and conditional jumps are done, followed by 
data move operations from register to register. A 
test of the and, or, and exclusive or instructions is 
then run. Each byte of a double register (16-byte) 
is incremented and decremented separately to see 
the effect on its companion register and on the 
Processor Status Word (flags, carry, parity, etc.). 
Exchange, register store, direct register add, deci- 
mal adjust, rotate left and rotate right instructions 
are then performed. Finally, a series of push and 
pop instructions combined with store directs and 
exchanges are executed to test as many applica- 
tion sequences as possible. 

The memory is well exercised as a part of the CPU 
test. The memory test executes a complete series 
of store directs into and load directs from memory 
via double CPU registers. This is done to insure 
proper functioning of all memory locations. 



Input/Output (I/O) 

One of the Intel® 8255 Parallel I/O Interfaces is 
addressed and programmed to be a set of three 
output ports. Alternate bit patterns 10101010 and 
01010101 (binary) are presented to each port and 



LEDs are attached to allow monitoring. The sec- 
ond Intel® 8255 is programmed as a set of three 
output ports. One of these ports is used to drive 
a Hne printer in recording failures. 

Serial I/O is tested periodically by manually re- 
setting the board and using a teletypewriter com- 
municating with the Monitor program. The auto- 
matic portion of the test is then restarted from 
this mode. 

Error Handling 

After the execution of selected compares and 
jumps, a routine is executed to record the occur- 
rence of any errors on a line printer and to stop 
processing. If the failure was catastrophic, the 
board would be removed and trouble-shot to deter- 
mine the failure mechanism. 

Temperature 

Twenty-one boards were tested at ambient temper- 
atures of +25°C, +55°C, and +70°C. The +55°C 
and +70° C elevated temperatures were used to 
increase stress on the boards and stimulate failures. 
(Tables IV and V on page 9 present the number of 
unit-hours run at each temperature.) 

BOARD RELIABILITY AND THE LIFE CURVE 

There is a fundamental principle of reUability engi- 
neering which predicts that the failure rate of any 
group of products implemented from integrated 
circuits will follow a curve such as that shown in 
Figure 8. 

This curve can be divided into three major cate- 
gories of failures: Infant Mortality, Random, and 
Wear Out. 



INFANT 
MORTALITY 



WEAROUT 



RANDOM 



-?J- 



TIME.t 



Figure 8. Reliability Life (Bathtub) Curve 
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Infant Mortality is that area of the curve where 
failures caused by manufacturing defects in both 
the components and/or the board are most appar- 
ent. Infant Mortality usually lasts from board 
manufacture to the low hundreds of hours of 
board operation. 

Random failures occur during the useful portion of 
the product hfe. These failures are a function of 
temperature, circuit complexity, device loading, 
and other factors. The Random failure rate ap- 
proaches a low constant value where it remains 
from hundreds to hundreds of thousands of oper- 
ating hours (for printed circuit boards with inte- 
grated circuits). Since it is the parameter of great- 
est interest to the system designer, the failure rate 
for SBC 80/10 Single Board Computers through 
the Infant and Random failure regions was ex- 
plored in reUability testing. During these tests, no 
evidence of wear out was experienced. Wear-out 
failures, as the name implies, occur when wear-out 
takes place, both physically and electrically, at the 
end of a device's useful Hfe. Statistically, this will 
not happen until hundreds of years have elapsed 
for LSI-based products such as the SBC 80/10 
Single Board Computer. 

Reliability Matliematics 

When information on the failure rate for a given 
LSI-based product is desired, that product gener- 
ally must have its life "accelerated" due to the low 
failure rates involved. This can be done by subject- 
ing the unit to high temperature, high voltage, or 
both. When high temperature is used, the thermal 
activation energy of failures can be used along with 
the failure rate at that temperature, to derive the 
effective failure rate at other temperatures. Such 
derivation is accomplished using the plot shown in 
Figure 9. This is an Arrhenius plot in which average 
time to failure (inverse of failure rate) is plotted 
against the reciprocal of temperature. The slope of 
the curve is related to the thermal activation 
energy in electron-volts. From these plots the 
effective failure rate at a given temperature may be 
derived from failure rate data determined at a dif- 
ferent temperature. The two failure rates are re- 
lated as follows: 

ETti = MF (ATt2) 
where : 

ETtj = Effective Time (hours) at Ti (Ambient 
Temperature) 

MF = MultipHcation Factor 

ATt2 "= T2 (Test Temperature) 



The Multiplication Factor (MF) is found from the 
expression: 

E. (±_1. 

k ITi T2; 



MF = exp < + 



where : 

MF 

E 

k 

Ti 
T2 



= Multiplication Factor 

= Thermal Activation Energy (eV) 

= Boltzmann's Constant 
(3.63 X 10-^eV/°K) 

= Ambient Temperature 

= Test Temperature 
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The thermal activation energy used in the calcula- 
tion is determined by the failure mechanism. Table 
II lists the most common failure mechanisms for 
MOS LSI devices. As can be seen from Table II, 
activation energies for n-channel MOS devices 
range from 0.3 eV to 1.4 eV. Bipolar devices have 
been shown to exhibit activation energy perform- 
ance at about 0.5 eV. Table III lists the most com- 
mon failure mechanisms for printed wiring assem- 
blies. 

A mixture of n-channel MOS LSI, bipolar SSI and 
MSI, and discrete components are used on the SBC 
80/10 Single Board Computer. The activation 
energy of the one failure during SBC 80/10 life 
testing could not accurately be determined. The 
failure occured in an Intel® 8224 clock generator 
at 460 hours into the test at an ambient tempera- 
ture of +25°C. This clock generator is sensitive to a 
+12V/-12V reversal of supply voltages which hap- 
pened once during the test. This may explain the 
one failure shown in Table IV. 



The Intel® 8080 life test program produced results 
indicating 0.5 eV as an appropriate activation 
energy for failure rate analysis (see Intel Reliability 
Report RR-10). An activation energy of 0.5 eV 
was used here as a conservative basis for failure rate 
conversion. 

Confidence Levels 

When calculating a failure rate, the simplest form 
of calculation is: 



Failure Rate 



Number of Failures 



(No. of Devices) X (No. of Hours Tested) 



The only problem in this equation is that the fail- 
ure rate thus calculated does not reflect a very high 
degree of confidence. In fact, the confidence level 
is only 50% for this equation. Since failures occur- 
ring beyond "Infant MortaHty" and before product 
"wear out" are random in nature, the average fail- 
ure rate for products operating in this region will 



Table! I 
COMPONENT FAILURE MODES 



FAILURE MODE 


TYPE 


ACTIVATION 
ENERGY (Eact) 


DETECTION 


Slow Trapping 
Contamination 
Surface Charge 
Polarization 
Electromigration 
Microcracks 
Contacts 
Oxide Defects 


Wear Out 
Wear Out/Infant 
Wear Out 
Wear Out 
Wear Out 
Random 
Wear Out 
Infant/Random 


1.0 eV 
1.4 eV 
0.5-1.0 eV 
1.0 eV 
1.0 eV 

0.3 eV 


High Temperature Bias 

High Temperature Bias 

High Temperature Bias 

High Temperature Bias 

High Temperature Operating Life 

Temperature Cycling 

High Temperature Operating Life 

High Voltage Operating Life and Cell Stress 



Table III 
PRINTED CIRCUIT FAILURE MECHANISMS 



FAILURE MODE 


TYPE 


DETECTION 


PREVENTATIVE MEASURES 


Fractured Wirewrap 

Gold Finger Contamination 


Random 
Random 


Visual & Functional 
Visual & Functional 


Proper Tool Handling 
Cleanliness, Gold Thickness 
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follow a Normal probability distribution. Such a 
distribution is shown in Figure 10. In Figure 10, 
the failure rate curve shows failure rate on the 
abscissa (X axis) and the failure frequency on the 
ordinate (y axis). The 50% confidence level is 
synonymous with the mean point of the curve and 
simply means that, in the population of product 
units, 50% of the units will have a failure rate less 
than or equal to the observed failure rate. The 90% 
confidence level is the 90th percentile of the distri- 
bution and means that 90% of the parts will have a 
failure rate less than the quoted number. 

Of course, the failure rate at the 90th percentile is 
much higher than at the 50th percentile and deter- 
mination of the failure rate at a 90% confidence 
level of greatest interest. Since the failure rate for 
random failures follows a Normal probabiUty 
distribution, the Chi-squared probability function 
provides a direct tool for derivation of failure rates 
at various confidence levels. Using the Chi-squared 
function, the failure rate can be calculated at any 
confidence level by: 



Failure Rate = 



X^(l -CL, 2r + 2) 
2nt 



where: 

X^ = Chi-square function 
GL = Confidence level expressed as a decimal 
r = Number of rejected boards 
n = Number of boards tested 
t - Total test time 

The values of x may be found in most texts on 
statistics where the 2r + 2 term is treated as the 
degree of freedom (DF). Given these tools for 
analysis, let us fully examine the results of the life 
test performed. 

LIFE TEST RESULTS 

The results of the SBC 80/10 life test program are 
described in Tables IV, V, and Vt. If the data from 
Table IV is used along with the information from 
the reliability mathematics section, the +25°C 
MTBF for the SBC 80/10 Single Board Com- 
puter at a confidence level of 90% is 91,739 hours 
(failure rate =1.09% per 1000 hours). A high 
temperature analysis was done concurrently with 
the +25°C program. As shown in Table VI, the 
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X (mean) 
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CONFI- 
DENCE 
LEVEL 



FAILURE RATE 

NOTE 1: ALL BOARDS AT A GIVEN CONFIDENCE LEVEL 

HAVE FAILURE RATE < THE FAILURE RATE AT THAT LEVEL 



Figure 10. Failure Rate vs. Failure Frequency 
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SBC 80/10 Single Board Computer is shown to 
have an MTBF of 25,006 hours (failure rate = 
3.99% per 1000 hours) with a confidence level of 
90% when operated continuously at ambient 
temperatures of +55°C (specified maximum 
ambient temperature for SBC 80/10 computer 
operation). 

Field Data 

The SBC 80/10 Single Board Computer was intro- 
duced in early 1976. Based on the number of SBC 



80/10 Single Board Computers shipped to date, a 
conservative estimation of actual unit running time 
provides an experience of more than 2,579,000 
unit-hours of operation. Intel field service has 
experienced 18 SBC 80/10 computer failures dur- 
ing this operational period. This data yields a 
90,845-hour, +25°C MTBF at a 90% confidence 
level (25° C operation assumed for all unit-hours). 
This correlates well with the results of the life 
testing program. 



Table IV 
LIFE TEST DATA EXTRAPOLATED TO 25°C 



TEST TEMPERATURE 


+25°C 


+55° C 


+70° C 


TOTAL 


FAILURES 


Unit-Hours @ Temperature 
Equivalent Unit-Hours @ +25°C 


24663 
24663 


14296 
84624 


20020 
256580 


365867 


1 
1 



Table V 
LIFE TEST DATA EXTRAPOLATED TO 55°C 



TEST TEMPERATURE 


+55° C 


+70°C 


TOTAL 


FAILURES 


Unit-Hours @ Temperature 
Equivalent Unit-Hours @ +55°C 


14296 
14296 


20020 
43345 


57641 







Table VI 
LIFE TEST RESULTS 





FAILURE RATE PER 


MTBF, 


TEST TEMPERATURE 


1000 hours 


hours 




90% UCL 


90% UCL 


+25°C 


1.09% 


91,739 


+55°C 


3.99% 


25006 



SUMMARY 

As a result of the reliability tests and Intel's relia- 
bility program, the SBC 80/10 Single Board Com- 
puter has demonstrated an MTBF of 25,006 hours 
at 90% confidence level when operated at 55°C. 
Stated another way, if a system using an Intel® 
SBC 80/10 Single Board Computer were used 24 
hours a day at an average ambient temperature of 
55°C, there is a 90% probability that such a system 
will operate for almost 35 months before the sys- 
tem would fail due to an SBC 80/10 computer fail- 



ure (over 10 years at +25° C operation). Of course, 
the system failure rate would be somewhat higher 
due to the failure rates of other elements in the 
system. 

The SBC 80/10 Single Board Computer was 
introduced in January, 1976, and has become an 
industry standard. Intel's system of manufacturing 
microcomputer systems, coupled with extensive 
rehability monitoring and tests, has yielded a high 
reliability, low-cost product - the SBC 80/10 
Single Board Computer. 
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INTRODUCTION 

This report presents reliabilty tests and support- 
ing data for the Intel iSBC 86/12A Single Board 
Computer with the optional iSBC 300 32K Byte 
RAM Expansion Module and the iSBC 340 16K 
Byte EPROM/ROM Expansion Module. The 
iSBC 86/12A Single Board Computer is a complete 
computer system on a single printed circuit board; 
the CPU, system clock, read/write memory, read- 
only-memory, I/O ports, serial communications 
interface, priority interrupt logic, programmable 
timers, bus control logic and drivers all reside on 
the board. The optional memory expansion 
modules attach to the board, allowing the on-board 
RAM to be expanded by 32K bytes (for a board 
total of 64K bytes), and the on-board EPROM/ 
ROM to be expanded by 16K bytes (for a board 
total of 32K bytes). 

A complete reliability testing program has been 
implemented to ascertain the reliabilty level of the 
Intel iSBC 86/12A microcomputer and the iSBC 
300 and iSBC 340 Expansion Modules. This report 
presents a review of this program, including a 
discussion of the test configuration utilized, the 
system exerciser/ diagnostic software used, the 
number of hours of testing performed and the 
ambient test temperatures. High temperature 
testing was performed to accelerate product aging 
and to provide operational data on the reliability 
performance of the iSBC 86/12A microcomputer at 
elevated temperatures. 

A full description of the quality assurance 
procedures that all of Intel's complete line of single 



board computers undergo prior to shipping is also 
included. 

iSBC 86/12A " BOARD DESCRIPTION 

The iSBC 86/12A Single Board Computer is 
contained on a 6.75 by 12 inch (17.15 by 30.48 cm) 
printed circuit board. Figure 1 shows an overall 
block diagram of the board. Intel n-channel MOS 
LSI technology and bipolar TTL are the basis for a 
full computer on a single PC board. Such a single 
board approach is inherently more reliable than 
traditional multiboard implementations through 
minimization of inter-board connectors. 

The heart of the iSBC 86/12A Single Board 
Computer is the Intel 8086 16-bit microprocessor 
(CPU). The 8086 CPU includes four 16-bit general 
purpose registers, which may also be addressed as 
eight 8-bit registers. In addition, the CPU 
contains two 16-bit pointer registers and two 
16-bit index registers. Four 16-bit segment 
registers allow extended addressing to a full 
megabyte of memory. 

The standard iSBC 86/1 2A microcomputer in- 
cludes 32K bytes of read/write memory; con- 
nectors are provided to allow the addition of up to 
16K bytes of programmable read only memory in 
IK, 2K, or 4K byte increments. Intel EPROMs are 
used for programmable read only memory. Up to 
32K bytes of additional on-board RAM and 16K 
bytes of additional EPROM can be added to the 
standard iSBC 86/1 2 A board with the iSBC 300 
and the iSBC 340 Expansion Modules, respective- 
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Figure 1. iSBC 86/12A^'' Single Board Computer Block Diagram 
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One Intel® 8255A Programmable Peripheral 
Interface device supplies 24 programmable 
parallel I/O lines. These lines are routed to 
sockets on the board that are used to buffer lines 
programmed as outputs with TTL drivers or to 
terminate lines programmed as inputs with iSBC 
901 or iSBC 902 resistor terminator packs. 

For serial communication, an Intel® 8251A 
Universal Synchronous/Asynchronous Receiver/ 
Transmitter (USART) is part of the iSBC 86/12A 
board. Additional circuitry provides jumper- 
selectable Teletypewriter (20 mA current loop) or 
RS232C compatible interfaces for the USART. 

For further information on detailed operation of 
the iSBC 86/1 2A microcomputer, consult the Intel 
iSBC 86/12A Single Board Computer Hardware 
Reference Manual. 



SINGLE BOARD COMPUTER QUALITY 
ASSURANCE 

The reliability of a board level product like the 
Intel iSBC 86/1 2 A Single Board Computer is a 
function of the quality of components used on the 
board, care in board design and fabrication, and 
the extent of testing performed on the product 
before shipment. An examination of each of these 
functions will provide an understanding of the 
Intel quality assurance program for micro- 
computer system products. 



Component Quality Assurance 

Standard Intel component quality assurance 
processing and 100% screening are applied to all 
Intel components used on the iSBC 86/12A 
microcomputer before they are assembled on the 
board. Once a component device has been quali- 
fied as reliable and transferred to systems level 
manufacturing, it is imperative that complete 
process controls are in effect to assure the 
continuation of high quality. Intel's component 
Q A flow centers around a series of acceptance 
gates between process entities (see Figure 2) and 
detailed inspection within the processing areas at 
critical points. For example, in wafer processing, 
furnaces are routinely monitored for contamina- 
tion through the use of capacitance voltage 
measurements on test chips. Also, electrical tests 
such as breakdown strength measurements are 
performed on test patterns on each wafer. Routine 
high magnification scanning electron microscope 
examinations at critical process steps also provide 
important process control feedback. A final QA 
acceptance is performed on all lots prior to 
shipment to assembly locations. 
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Figure 2. Component QA Flow Diagram 

Table 1 details the Intel component Q A acceptance 
gates within the assembly flow and identifies the 
appropriate method employed per MIL-STD-883. 
During the test and finishing operation, QA 
maintains standards, test tape and calibration 
control of all production equipment. Final QA 
inspection is performed after the mark and pack 
operation. 

Table 1. Component Assembly Flow 



OPERATION 


MIL-STD-883 
METHOD 


Piece Part Inspections 




Scribe and Break 




QA Acceptance 
2nd Optical Inspection 


2010.18 
2010.18 


Lead Bond 




QA Acceptance 
3rd Optical Inspection 


2010. IB 
2010.18 


Seal 




Temperature Cycle 


1010 (C) 


QA Acceptance 
Fine Leak 


1014 (8) 

1014 (A) 

(10^ atm cc/sec) 


QA Acceptance 
Gross Leak 


1014 (C) 
1014(C) 


QA Acceptance 
Final Visual 


2009 
2009 
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Board Assembly 

Figure 3 shows the stringent cycle of inspection 
and testing each board undergoes before being 
shipped to the customer. After bare board manu- 
facture, boards are inspected for raw board quahty 
conformance (i.e., hole registration, drilling, 
laminate integrity, artwork registration, etc.), and 
tested for trace "shorts" and "opens". 

Components for an assembly "kit" are then pulled 
together and made ready for the assembly 
operation. Visual inspection of each kit of 
components is then conducted. The kit is assem- 
bled onto the bare board and the assembled parts 
of the board are inspected prior to wave solder for 
proper location and after wave solder for soldering 
defects. Final assembly inspection insures the 
boards are ready for test. 
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Board Production Testing 

Manufacturing testing, though not a part of 
reliability testing per se, is very effective in 
eliminating ''infant mortality" failure. These 
types of failures, by their nature, occur in the early 
life of a product. Each iSBC 86/1 2A microcom- 
puter is pre-baked at 70°C prior to any testing. 
Figure 4 shows some of the ovens used in this 
process. The boards are allowed to cool and then 
exhaustively tested on a Teradyne L125 Digital 
Diagnostic Tester. Use of a special "bed of nails" 
vacuum test fixture insures that all critical board 
test points may be accessed by the test system. 
Figure 5 shows the test fixture for the iSBC 86/1 2 A 
board, and Figure 6 shows one of the Teradyne test 




Figure 4. Ovens Utilized for Board Pre-Bake 




Figure 3. Board Manufacture 
and Test Flow/Screening 



Figure 5. ISBC 86/12A"' Single Board 
Computer Test Fixture 
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systems used in Intel microcomputer board-level 
testing. Failed components are replaced, and the 
boards are retested on the Teradyne test system. 



When the boards have passed this thorough 
testing, they are then "system tested" to guarantee 
Intel® MULTIBUSTM interface integrity. This 
consists of installing a set of monitor and 
diagnostic program memory EPROMs into the 
four iSBC 86/1 2A EPROM sockets, applying all 
necessary voltages, and monitoring the iSBC 
86/1 2A board's performance with a CRT terminal 
(see Figure 7). The monitor/ diagnostic exerciser 
program tests the CPU, dual port memory, I/O 
interfaces, and MULTIBUS interface in a multi- 
processing environment. After test, the boards are 
inspected for possible test damage. Boards 
passing this final screening are then released by 
Intel Quality Assurance to Intel's standard 
product warehouse. Each product shipped is also 
subject to an audit. This audit consists of a 
complete review of documentation, test, functional 
performance, workmanship and handling. 




Figure 6. A Teradyne Test System Utilized 
in iSBC 86/12A^" Board Testing 

Environmental and Temperature Testing 

Intel's Advance Reliability/Quality Assurance 
Department also performed a series of environ- 
mental and temperature tests on production 
versions of the iSBC 86/12A Single Board 
Computer, the iSBC 300 RAM Expansion Module 
and the iSBC 340 EPROM/ROM Expansion 
Module. These tests were designed to assure that 
the boards can withstand the worst conceivable 
physical and temperature conditions that might 
be found in a light commercial or industrial 
environment. A light commercial or industrial 
environment is defined as an area with moderate 
temperature and humidity, suitable for occupation 
by operating personnel, as for example an office or 
a manufacturing plant. 



The temperature tests were performed in Intel's 
Environmental Testing Laboratory in Hillsboro, 
Oregon. VIKING LAB, an independent labor- 
atory in Mountain View, California, was engaged 
to perform the environmental tests, which 
consisted of vibration, shock and humidity 
testing. 

The iSBC 86/1 2 A board was tested in two test 
configurations. In one configuration, two iSBC 
86/12A boards were installed in an iSBC 604 
cardcage and exercised in a master/slave multi- 
processing environment. The other configuration 
was identical except that an iSBC 300 Expansion 
Module and an iSBC 340 Memory Expansion 
Module were connected to each iSBC 86/1 2A board 
in the test configuration. When possible, each of 
the board configurations were tested concurrently. 
The programs to exercise the boards during the 
various environmental and temperature tests were 
contained on EPROMs installed on each iSBC 
86/12A board. 

Two parallel I/O ports were used as test monitors 
with specially designed LED fixtures. A CRT 
terminal connected to the serial I/O port was used 
to start the test and monitor the system testing. 

Both boards in each board configuration were 
exercised over the MULTIBUS interface, which in 
turn exercised the Intel® 8289 Bus Arbiter. Dual 
port exchange was exercised as well between 
RAMs. Approximately 80% of the CPU's instruc- 
tion set was exercised. 

The EPROM on each board exercised and checked 
its resident RAM (and expansion module RAM 
when present) as well as the RAM (and expansion 
module RAM) on the companion board. This 
cross checking allowed maximum exercising of 
the boards. The exercise routines were then 
looped to provide continuous operation of the 
boards before, during, and following the various 
environmental and temperature tests. 



Vibration 

For the vibration tests, the two board configura- 
tions were tested on a horizontal vibration table in 
all three axes (X, Y and Z). On each axis the 
vibrations applied were cycled up and down 
between 10 and 55 Hz, with a total cycle time of iy2 
hours. E ach major resonance point was dwelled at 
for 15 minutes, during which time a strobe light 
was used to observe the relative movement 
between boards. If no resonance points were 
observed during the first half of the test cycle, the 
15 minute dwell was performed at 55 Hz. At the 
completion of the test of each axis, a visual 
inspection of the boards was performed. The iSBC 
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Expansion modules removed in second test configuration. 

Figure 7. Block Diagram of Test Set-Up 



86/12A board, ISBC 300 and iSBC 340 modules 
passed the vibration test without failure. This test 
is intended to simulate an environment with low 
level vibrations such as those caused by a large 
industrial motor or machine, or as might be found 
in a mobile installation. 

Shock 

In testing the ability of the board configurations to 
withstand shock, the board configurations were 
subjected to 30g shocks for 11 jusec (V-i sinewave). 
Shocks were applied to each of the six sides of the 
board configuration, 12 shocks per side. A 
performance test cycle was performed before, 
during, and following each shock; a visual 
inspection was performed at the completion of the 
test of each side. At the end of the shock test, a 
post-test performance test was performed. No 
visual damage was noted as a result of the shock 
tests to the iSBC 86/12A boards or the iSBC 300 or 
iSBC 340 modules, nor did the tests have any effect 
on the performance of the boards. This test 
simulates typical shipping conditions with 
commercial carriers and the kind of occassional 
shocks that occur from bumps or dropping a piece 
of equipment from a low height. 

Humidity 

Each board configuration was subjected to the 
following test cycle in a humidity chamber: (while 
operational) 

1. Relative humidity and temperature of the 
chamber was ramped up to 80% and 25°C 
(taking approximately 1 hour). 

2. Relative humidity was held at 80% for 2 hours. 



3. Relative humidity and temperature are then 
ramped up to 95% and 40 °C (taking approxi- 
mately 1 hour). 

4. Chamber is held at this state for 17 hours. 

5. Relative humidity and temperature are ramped 
down. 

This cycle was performed four times on each board 
configuration with no effect on the performance of 
the boards and no resulting board or component 
failure. These humidity conditions test the boards 
reliability not only at high humidity and 
temperature, but also accelerates the effects of 
moderate humidity over a long period of time. 

Temperature 

Three temperature related tests were performed on 
the board configurations: a non-operating test, an 
operating test, and a temperature vs. power supply 
voltage test. For the non-operating test, the board 
configuration was exercised, then placed in a 
-40°C environment for 2 hours. After removal 
from this environment, the board configuration 
was allowed to stabilize for 1 hour and then it was 
exercised again. This test was repeated at 75 °C. 

For the operating test, the board configuration 
was exercised at 55 °C for 16 hours, turned off and 
allowed to stabilize for Vi hour at room 
temperature, then operated for 1^2 hours at 
0°C. These non-operating temperature tests are 
intended to simulate worst case storage or 
transportation temperatures. 

For the temperature vs. power supply voltage test, 
the three power supply voltages (+5V, -5V and 
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-12V) are adjusted first to their -1-5% tolerance 
extreme and then to their -5% tolerance 
extreme. At each of these settings, the board 
configurations were exercised for 2 hour intervals 
both at 0°C and +d5°C. These two procedures test 
the ability of the boards to continue operating in 
extremes of a light commercial or industrial 
environment and under the combined conditions 
of extreme temperature variation and poorly 
adjusted or unstable power supply voltages. 

The iSBC 86/12A, iSBC 300 and iSBC 340 boards 
performed without problem through each of these 
temperature tests. 



Summary 

Having been subjected to these tests as a part of 
Intel's reliability testing program, the iSBC 
86/12A Single Board Computer, the iSBC 300 32K 
Byte RAM Expansion Module, and the iSBC 340 
16K Byte EPROM/ROM Expansion Module have 
demonstrated a high reliability/confidence level. 

The reliability of these boards will be further 
monitored through continued reliability testing, 
Intel's production quality assurance program and 
the analysis of field reports. Evidence of failures 
will be distilled back into the engineering process 
and used in refining quality assurance testing 
procedures. 
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Technology 




Reduce your AtC-based system design time 

by using single-board microcomputers. Assembled boards 
in the SBC-80 series offer stock answers to custom demands. 



System designers eager to take advantage of the 
dramatically increased capabilities of micro- 
computers have been hindered two ways: Their pro- 
duction volumes have been too low to amortize soft- 
ware and hardware development costs effectively, or 
hardware subtleties and test requirements have con- 
fined them to fully assembled and tested computer 
subsystems. But now those obstacles are overcome 
with families of fully assembled and tested micro- 
computers and system-expansion boards like the Intel 
SBC-80 series. They are ready-to-use, flexible and 
inexpensive— prices range from just $195 to $825 in 
unit quantities. 

The main members of the SBC-80 family are the 
80/04, 80/05, 80/lOA, 80/20 and 80/20-4 central- 
processor boards, with either an 8080A or 8085 micro- 
processor acting as the master CPU (Table 1). Most 
of the boards measure 6.75 X 12 in. and contain the 
CPU, clock, read/write memory, control ROM, I/O 
ports, serial communications interface and bus-con- 
trol logic. 

I/O interfacing is an area where design flexibility 
is essential to meet changing requirements efficiently. 
The programmable parallel and serial I/O structures 
of the boards make them versatile enough to do just 
that. What's more, upgrading system performance is 
easy thanks to the SBC-80 system bus, the Multibus, 
which permits modular performance expansion. 

The Multibus provides a defined, standard interface 
between the SBC-80 single-board computers and ex- 
pansion boards. As many as 16 SBC-80 family boards 
can simultaneously share the bus. 

All in the SBC-80 family 

As exemplified by the block diagram of the 
SBC-80/10A (Fig. 1), the SBC-80 microcomputer sys- 
tem has all that's needed for many applications. The 
SBC-80/10A is the oldest board in the family and has 
been widely imitated since it was one of the first 
"standardized" microcomputers commercially avail- 
able. 

The CPU section of the 80/lOA board consists of 



George Adams, Product Line Manager, Single-Chip Micro- 
computers. Intel Corp., 3065 Bowers Ave., Santa Clara. 
CA 95051. 



the 8080A CPU, the 8224 clock generator and the 8238 
system controller. Capable of fetching and executing 
any of the 8080A's 78 instructions, the CPU section 
can respond to interrupt requests originating on and 
off the board. (For more about the 8080A, see "Micro- 
processor Basics, Part 2," ED No. 10, May 10, 1976, 
p. 84). 

The system-bus interface section includes an assort- 
ment of circuits to gate the interrupt arid hold re- 
quests, the ready signals, and a systep-reset signal. 
Other circuits drive the various control lines. Two 
8216s help drive the bidirectional data bus, and six 
8226s drive the external system-d^ta and address 
buses as part of the SBC-80/lOA's Multibus interface. 

The RAM section of the 80/lOA consists of 1024 
bytes of static MOS memory. For program storage, 
up to 8192 bytes of ROM can be mounted on the board 
in 1024-byte increments by means of a 2708 or 8708 
EPROM, an 8308 mask-programmed ROM, or in 2048 
byte increments via the 2716 EPROM or 2316 ROM. 

A serial interface on the board uses an 8251 pro- 
grammable universal synchronous/asynchronous 
receiver/transmitter to provide a serial-data channel. 
The serial port operates at programmable rates up to 
38,400 baud (synchronously) or 19,200 baud (asynchro- 
nously) with a choice of character length, number of 
stop bits, and even, odd or no parity. On-board 
interfaces provide direct EI A RS-232 or teletypewriter 
current-loop compatibility. 

Two 8255 programmable peripheral interface 
circuits provide 48 I/O lines for transferring data to 
or from peripheral devices. Eight already-committed 
lines have bidirectional drivers and termination 
networks permanently installed, so that they can be 
inputs, outputs or bidirectional (jumper-selectable). 
The other 40 lines are uncommitted. On-board sockets 
permit drivers and termination networks to be in- 
stalled, as needed. Since software configures the I/O 
lines, I/O can be customized for every application. 

The 80/lOA also responds to a single-level interrupt 
that can originate from one of many sources, the 
USART, programmable I/O and two user-designated 
interrupt-request lines; When an interrupt is recog- 
nized, a Restart-7 instruction is generated, and the 
processor accesses location 38h to get the starting 
address of the service routine. 

System expansion and support are possible with a 



Note: Multibus, RMX-80, ICE and Intellec are registered trademarks of Intel Corp. 
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wide variety of alternate-source CPU, memory, and 
I/O boards (Tables 2 and 3). Up to 65,536 bytes of ROM, 
PROM or RAM can be accessed by one 80/lOA. 
Expandable backplanes and card cages are also avail- 
able to support multiboard systems. 

Interfacing starts with the bus 

Although the SBC-80/10A is a complete micro- 
computer system, it can be expanded readily or it can 
serve as a primary master controller for other micro- 
computer cards. The 80/lOA has five edge connectors, 
three on the top of the board and two on the backplane, 
or bottom, side. Two of the "top" connectors, Ji and 
J2, serve as parallel I/O ports, while J3 is a serial I/O 



port. All parallel I/O lines on the 50-contact Ji and 
J2 connector areas are paired with an independent 
signal/ground pin to permit alternate signal/ground 
wiring when using flat-cable interconnects. Serial port 
J3 uses a 26-contact PC-edge connector to provide 
interfaces for both RS-232 and current-loop devices. 

To communicate with other system-compatible 
boards, the 80/lOA uses the 86-pin Multibus (P,). To 
provide accessible test points, the 80/lOA has a 60- 
pin edge connector (P2). The control signals on the 
Multibus provide the real power and capability in 
control applications. 

Of the 86 pins that make up the Multibus, 24 are 
assigned to power and ground, 16 to addressing, eight 
to bidirectional data, and 12 to signal and control 
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1 . Based on an 8080A ^P. the 80/lOA microcomputer has 

a straightforward design suitable for general-purpose 
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computing and control. The board has 48 programmable 
I/O lines and serial interfaces. 



1/0 DEDICATED TO 
MASTER NO. I 



CPU MASTER NO. I 
SBC 80/20 



MEMORY I/O 



BUS CONTROL 



COMMON HIGH 
SPEED MATH 
PROCESSOR 
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AND PERIPHERALS 



I/O DEDICATED TO 
MASTER NO. 2 



<w> 



MEMORY 

ZTEZ 



BUS CONTROL 



CPU MASTER NO. 2 
SBC 80/05 



2. The Multibus interface for the SBC-80 CPU boards not 

only permits simultaneous multiprocessing, but also 
enables several processors to share the same bus and 



peripheral devices. Arbitration logic on the CPU boards 
decides which board gets on the bus first if several units 
simultaneously access the bus. 



(these 12 are defined in Table 4). The remaining 26 
pins are unassigned at this point. Higher capability 
SBC-80 products, though, are in development. These 
boards will use many of the unassigned lines (eight 
unassigned pins are allocated for additional bidirec- 
tional data lines). The remaining lines provide multi- 
level (eight) interrupt lines, various control lines and 
a multimaster, bus-arbitration control structure (Fig. 
2). Address and data lines are three-state, and the 
interrupt and control lines are open-collector. 

Boards using the Multibus have a master-slave 
relationship: A bus master— such as an SBC 80 CPU 
board, a DMA controller or a diskette controller— can 
control the command and address lines. Conversely, 
slave boards— such as a memory, I/0-expansion or 
mathematics boards— cannot control the bus. 

Arbitration resolves priority disputes 

In mul timast er systems, the bus-arbitration logic 
uses the CCLK signal of the bus to provide a timing 
reference to help satisfy many simultaneous requests 
for bus control. As a result, different speed masters 



can share resources on one bus. Actual transfers on 
the bus proceed asynchronously with respect to the 
bus clock. Once bus access is granted, single or 
multiple read/write transfers can proceed at up to 150 
kbytes/s for CPU operations and up to 1 Mbyte/s for 
DMA operations. The bus has a bandwidth of 5 
Mbytes/s so that future performance enhancements 
may be directly supported. 

Both serial and parallel modes of bus-priority reso- 
lution are available. In the serial mode, up to three 
masters can share the system bus, with requests 
ordered on the basis of bus location. Each master on 
the bus notifies the next one down in priority when 
it needs to use the bus, and monitors the bus-request 
status of the closest higher-priority master. With an 
external priority network, up to 16 masters can share 
the bus. 

The dual-bus nature of the Multibus permits each 
processor-based master within the system to retain 
its own local memory and I/O, which it uses for most 
operations. Such local operations occur entirely on the 
individual board and don't require the system bus. 

In contrast to the dual bus architecture, all masters 



Table 1. Comparison of SBC-80 CPUs 





SBC 80/04 


SBC 80/05 


SBC 80/lOA 


SBC 80/20 


SBC 80/20-4 


CPU 


8085 


8085 


8080A 


8080A 


8080A 


EPROM capacity (bytes) 
(with 2716) 


4096 


4096 


8192 


8192 


8192 


(with 2708) 


2048 


2048 


4096 


4096 


4096 


RAM (bytes) 


256 


512 


1024 


2048 


4096 


Programmable parallel 
I/O lines 


22 


22 


48 


48 


48 


Serial I/O capability 


RS232C 
SID/SODi- 2 


RS232C 
SID/SOD^- 2 


RS232C/TTY 
USART 


RS232C2 
USART 


RS232C2 
USART 


Timers 


1 


1 





2 


2 


Interrupt levels 


4 


4 


1 


8 


8 


Multibus interface 


None 


Multi-master 


Single-master 


Multi-master 


Multi-master 


Price (unit quantity) 


$195 


$350 


$495 


$735 


$825 



Notes: 'Provided by 8085 CPU SID and SOD serial I/O lines. ^Optional SBC 530 TTY interface is available. 
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Table 2. Additional SBC support boards 



Function 



RAM 



EPROM 



Digital 
I/O 



Communi- 
cations 



Analog 
I/O 



Combina- 
tion 

memory 
and I/O 



Model 



SBC 016 
SBC 032 
SBC 048 
SBC 064 
SBC 094* 



SBC 416 



SBC 508* 



SBC 517 



SBC 519* 



SBC 534 



SBC 556* 



SBC 711* 



SBC 724* 



SBC 732* 



SBC 104 



Description 



16 kbyte dynamic RAM 
32 kbyte dynamic RAM 
48 kbyte dynamic RAM 
64 kbyte dynamic RAM 
4 kbyte CMOS static 
RAM with 96 hour bat- 
tery backup. 



16 kbytes using 2708 
type (1024x8) EPROM 



32 input lines/32 out- 
put lines, all buf- 
fered/terminated 

48 programmable par- 
allel lines with full 
buffering/termination 
options, full RS232C 
port, 1 ms real-time 
clock, and 8-line inter- 
rupt control 

72 programmable par- 
allel lines with full 
buffering/termination 
options, real-time 
clock (interval is 
jumper selectable to 
0.5. 1. 2. or 4 ms). and 
8-level programmable 
interrupt control. 



Four programmable 
synchronous/asyn- 
chronous serial ports, 
each with: program- 
mable baud rates, pro- 
grammable data for- 
mats, programmable 
interrupt control, 16 
RS232C buffered pro- 
grammable parallel 
I/O lines configured as 
a Bell Model 801 auto- 
matic calling unit in- 
terface. Two program- 
mable 16-bit interval 
timers (usable as real- 
time clocks), and soft- 
ware selectable loop- 
back of serial ports for 
diagnostic use. 

48 optically isolated 
lines; 24 input 16 out- 
put, and 8 program- 
mable (in/out), 8-level 
programmable Inter- 
rupt control, and 1 ms 
real-time clock. 



16/8 (single-ended/ 
differential) 12-bit a/d 
channels; user expan- 
dable on-board to 
32/16 channels 

Four 12-bit d/a chan- 
nels 

Combination analog 
I/O; same a/d capabili- 
ty as SBC 711 plus 2 
d/a channels 



8 kbytes capacity 
(sockets) using 2716 
(2 k X 8) EPROM or 4 
k using 2708. 4 kbytes 
dynamic RAM, 48 pro- 
grammable parallel 
I/O lines, with full buf- 
fering/termination, as 
options. RS-232C port, 
a 1 ms real-time clock, 
and an eight-line inter- 
rupt control 



Price 
(unit 
qty) 



$ 825 
$1360 
$1860 
$2200 
$ 795 



$ 295 



$ 350 



400 



$ 395 



$ 650 



$ 395 



$ 895 



$ 750 



$1125 



$ 715 



in multimaster/single-bus systems use the common 
bus for all instruction or data fetches or whenever 
data must be written to output devices or memory. 
Rapidly, then, the system bus becomes the bottleneck 
for over-all system throughput. Masters in SBC-80 
systems only use the Multibus when data or instruc- 
tions are resident in common, or global, memory or 
I/O. Since masters can request the Multibus simulta- 
neously, on-board arbritration logic resolves any mul- 
tiple contention. 

Examine board performance 

A look at the entire family of SBC-80 micro- 
computers reveals varied levels of performance. All 
five boards are inexpensive, but the most inexpensive 
is the 80/04, which costs $99 in 100-unit quantities, 
and is intended for stand-alone applications. To get 
the cost down, the board was designed to use the 8085 
CPU and the 8155 RAM, timer and I/O circuit. 

The 80/04 contains an 8085 CPU, 256 bytes of RAM, 
space for up to 4 kbytes of EPROM (two 2716 EPROMs, 
or two 2708 EPROMs), 22 programmable parallel I/O 
lines with sockets for buffer and termination options, 
a 14-bit programmable timer/event counter, and pro- 
vision for an RS-232-C serial port using the 8085 
SID/SOD serial interface. The board can also house 
an on-board +5-V regulator, so an unregulated voltage 
can be connected. 

The next step up, the 80/05, has the same architec- 
ture and connector types and pinouts as the 80/04. 
Direct software compatibility is achieved with the 
same CPU along with the same RAM, ROM, I/O, and 
timer addressing. However, the 80/05 contains twice 
as much RAM as the 80/04. And since the 80/05 has 
the full Multibus multimaster interface, 80/05-based 
systems can be expanded with any of the Multibus- 
compatible boards from Intel or other suppliers. 

The SBC-80/10A comes next. It provides more on- 
board memory and I/O for systems requiring ex- 
panded on-board resources. Based on the 8080A CPU, 
the board contains 1 kbyte of RAM, up to 8 kbytes 
of EPROM/ROM, 48 programmable parallel I/O lines, 
a full USART serial port with RS-232-C and tele- 
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SBC 108 



SBC 116 



SBC 310* 



SBC 201 



SBC 202 



SBC 501 



Same as SBC 104. ex- 
cept has 8 kbytes of 
dynamic RAM 

Same as SBC 104. ex- 
cept has 16 kbytes of 
dynamic RAM 



High speed mathema- 
tics processor includ- 
ing floating-point ca- 
pability (32 bit). 



Dual single-density dis- 
kette controller 

Quad double-density 
diskette controller 



DMA controller, up to 
1 MHz transfer rates 
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$ 995 



$1290 



$ 450 



"Requires +5 V only. 
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typewriter interfaces, and a full Multibus interface 
(but only single-master capability; the board has no 
multimaster capability). Intended for single^CPU sys- 
tems with only one other Multibus peripheral con- 
troller, the 80/lOA can interface with such as the 
SBC-201 or SBC-202 single and double-density dis- 
kette controllers, or the SBC-501 DMA controller. 

System designers requiring the same on-board I/O 
capability as the SBC-80/10A but with more RAM, 
more efficient real-time capability, and full multi- 
master Multibus control can go further up the ladder 
to the SBC-80/20 or SBC-80/20-4. These boards differ 
only in that the 80/20 contains 2 kbytes of RAM and 
the 80/20-4 contains 4 kbytes. Both boards can hold 
up to 8192 bytes of ROM or EPROM, handle up 




INTERPROCESSOR BUS 
(TO SECOND SBC 80) 



3. Programmable I/O lines from the SBC-80 parallel 
interfaces can be set so that they are individually program- 
mable as inputs or outputs (a), byte-programmable as 
inputs or outputs with handshaking (b), or bidirectional 
on a byte-programmable basis (c). 



to eight levels of prioritized interrupt, and share the 
Multibus in the multimaster mode. Either board has 
two programmable interval timers/event counters. 
Auxiliary power buses and memory-protect control 
logic on the board permit battery backup of the RAM. 

Take advantage of interrupts and timers 

Real-time applications frequently require that high- 
priority programs operate on the basis of external 
events, time-of-day, or elapsed time without impact- 
ing current background processing. These multi- 
programming requirements are supported in the 
80/20 and 80/20-4 by an eight-level programmable 
interrupt controller (PIC) and two programmable 
interval timer/event counters. The priority level of 
any event generating an interrupt request is assigned 
through jumper selection and the priority algorithm 
chosen by system software. 

Any combination of interrupt levels may be masked 
by storing a single byte in the interrupt-mask register 
contained by the PIC, whose four software-selectable 
priority algorithms are described in Table 5. The PIC 
generates a unique memory address for each interrupt 
level. These addresses are equally spaced at intervals 
of 4 or 8 bytes (software-selectable). The resulting 32 
or 64-byte block may begin at any 32 or 64-byte 
boundary in the 65,536-byte memory space. A single 
8080A jump instruction at each of these addresses 
then provides linkage to locate each interrupt service 
routine independently anywhere in memory. 

The two programmable timers may be used to 
generate real-time clocks by requesting periodic inter- 
rupts through the PIC, so that the CPU is free to 
handle numerous other system-timing and control 
functions. The outputs and gate/trigger inputs of the 
timer/counters can be routed via jumpers to the PIC, 
the I/O driver/terminators, or the programmable 
parallel I/O. 

Seven software-selectable timing/counting func- 
tions are available. Either timer may be set to act as 
a rate generator (divide-by-N counter), a square-wave 
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4. By using the RMX-80 executive and the library of often- 
used subroutines, program development can be simplified 
since the subroutines are modular and can be linked 
together, then checked out in a system prototype. 
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Table 3. Non-Intel SBC-compatible boards 
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ADAC Corp., 118 Cummings Park, 
Woburn, MA 01801.(617) 935-6668 










• 


















451 


Ampex, Memory Products Div., 200 N. Nash St., 
El Segundo, CA 90245.(213) 640-0150 






• 






















452 


Analog Devices, Route 1 Industrial Park, 

P.O. Box 280, Norwood, MA 02062.(617) 329-4700 










• 


















453 


Augat Inc., 33 Perry Ave., P.O. Box 779, 
Attleboro, MA 027(33.(617) 222-2202 


























• 


454 


Burr-Brown, International Airport Industrial Park, 
P.O. Box 11400, Tucson, AZ §5734.(602) 294-1431 










• 


















455 


Cybernetic Microsystenns, 2460 Embarcadero Way, 
Palo Alto, CA 943(53.(415) 321-0410 










• 














• 




456 


Data Translation Inc., 23 Strathmore Road, 
Natick. MA 01760.(617) 655-5300 





























457 


Datacube Corp.. 25 Industrial Park, 
Chelmsford. MA 01824. (617) 256-2555 






















• 






458 


Datel Systems Inc., 1020 Turnpike St., Building S., 
Canton. MA 02021.(617) 828-8000 










• 


















459 


Digidata Corp., 8580 Dorsey Run Road. 
Jessup.MD i0794.(301) 4^8-0200 














• 














460 


EDAC Corp., 1417 San Antonio Ave.. 
Alameda, CA 94501.(415) 521-6600 






















• 






461 


Electronic Engineering & Prod. Services, TE. #2, 
Louisville. TN 37///. (615) 984-9640 












• 
















462 


Electronic Solutions, 7969 Engineer Rd.. 
San Diego, CA 92111.(714) 292-0242 


• 


• 




• 




















463 


Garry Mfg. Co., 1010 Jersey Ave., 

New Brunswick, NJ 08902.(201) 545-2424 


























• 


464 


Hal Communications Corp., Box 365B, 807 E. Green St., 
Urbana. 1161801.(217)367-7373 






















• 






465 


lasis, 815W. Maude Ave.. 

Sunnyvale. CA 94086. (408) 732-5700 


• 


























466 


ICOM, 6741 Variel Ave., 

Canoga Park. CA 91303.(213) 348-1391 


















• 










467 


Megalogic Corp., 9650 National Road, 
Brookville, OH 45309.(513) 833-5222 
















• 












468 


Micro Memories Inc., 9438 Irond^le Ave.. 
Chatsworth. CA 91311.(213) 998-0700 






• 






















469 


Microtec, P.O. Box 60337. 
Sunnyvale, CA 94088.(408) 733-2919 








• 




















470 


Monolithic Systems Inc., 14 Inverness Drive, 
East, Englewood, CA 80110(303) 770-7400 


• 


• 
























471 


National Semiconductor, 2900 Semiconductor Drive, 
Santa Clara, CA 95051.(408) 737-5000 


• 


























472 


North Star Computers- Inc., 2465 Fourth St.. 
Berkeley, CA 94710.(415) 549-0858 
























• 




473 


The Thomas Engineering Co., 1201 Park Ave,. 
Emeryville. CA 94608.(415) 547-5860 




















• 








474 


Vector Electronic Products, 12460 Gladstone Ave., 
Sylmar. CA 91342.(213) 365-9661 


























• 


475 


Zia Tech., 10762 La Roda Drive. 
Cupertino, CA 95015.(408)996 -7082 














• 
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generator, a programmable retriggerable one-shot, or 
software or hardware-triggered strobe. One of the 
timers can be jumper-selected as an event counter, 
and either can generate an interrupt after a specified 
interval or after a specified number of events. 

The programmability of each on-board timer allows 
timing intervals from approximately 2 ^s to over 60 
ms. But the two timers may be cascaded to provide 
intervals greater than 1.1 hour, in 1.86 /jls increments. 
In the event counter mode, external event rates up 
to 1.1 MHz may be counted. 



Flexible I/O, a must for any system 

All SBC-80 microcomputers provide 22 or 48 pro- 
grammable parallel I/O lines that, grouped as 8-bit 
ports, are fully programmable to allow enough flex- 
ibility to handle any changes in system interfacing. 
Programmability is permitted through data direction, 
control mode, interrupt handling, and 
buffer/termination. The I/O configuration for a spe- 
cific application is selected through software in- 
itialization of the parallel I/O control logic, jumper 
selection of control/interrupt line routing, and the 
particular buffer and termination devices chosen. 

Fig. 3 illustrates the basic modes of operation that 
may be selected by software to meet application 
requirements. Mode is used for slow-to-medium- 
speed interfacing where immediate handshake re- 
sponse or interrupt generation is not needed. This 
mode is extremely useful for interfacing to inputs such 
as switches or outputs such as LED indicators or 
numeric displays. 

Mode 1 provides handshaking lines required for 
many medium to high-speed peripherals. A typical 
output function could be a line printer; an input device 
could be an encoded keyboard or paper tape reader. 

In addition, the 80/lOA and 80/20 have Mode 2, a 
bidirectional data/control structure. This interface 
may provide, for example, a communication link 
between parallel processors. 

The SBC-80 I/O structure also permits multiple 
options for output buffering and input termination. 
TTL drivers with 16 to 48 mA of drive can be used, 
and input lines may be terminated to minimize the 
impact of noise and cable disconnects. Any of the TTL 
drivers (four outputs) or input terminators (for inputs) 
listed in Table 6 may be inserted into sockets to provide 
proper buffering or termination. 

Like the design flexibility of the SBC-80 parallel I/O 
structure, the serial I/O structure allows interface 
characteristics to be revised rapidly through software, 
jumper, and buffer changes. Besides the SBC-80/10A, 
the 80/20 and 80/20-4 contain the USART serial 
channel. These boards provide RS-232 interfaces, but 
the SBC-80/10A also has a teletypewriter current-loop 
interface. Synchronous/asynchronous mode, data for- 
mat, control-character format, and parity are all 
under program control. So is baud rate on the 80/20 
and 80/20-4. Baud rate is jumper-selectable on the 



Table 4. Multibus control signals 


AACK 


Advance-acknowledge signal, used in 
8080A-based systems. It Is sent to the 
SBC-80 board by a memory bank in re- 
sponse to a memory-read command, allow- 
ing the memory to complete the access 
without requiring the CPU to wait. 


BCLK 


Bus clock, used to synchronize bus-control 
circuits on all master boards. It has a period 
of 101.725 ns (9.8304 IVTHz) and a 30to 70% 
duty cycle. The signal may be slowed, 
stopped or single-stepped. 


BPRN 


Bus-priority-input signal, used to indicate to 
the master that a higher-priority master 
board wants to use the system bus. When 
brought high, the signal suspends process- 
ing activity and places line drivers of the 
master in a standby mode. 


BUSY 


Bus-busy signal, a bidirectional control line 
that allows control and monitoring of the 
Multibus in multimaster systems. As an 
output from a bus master, BUSY Indicates 
the bus is being used by the board. It 
prevents all other master boards from gain- 
ing control of the bus. Each master 
monitors BUSY as an input to determine 
current Multibus usage status. 


CCLK 


Constant clock, used to provide a 9.8304- 
MHz cJock signal for optional memory and 
I/O expansion boards. CCLK coincides with 
BCLK and has a period of 101.725 ns and 
a 30 to 70% duty cycle. 


INIT 


Initialize signal, used to reset the entire 
system to a known internal state. 




Interrupt input, used to interrupt the proc- 
essor via an externally generated interrupt 
request. 


INTRl 


lORC 


l/O-read command, a signal generated by 
the master to indicate that the address of 
an input port has been placed on the 
system-address bus and that the data at 
that input port are to be read and placed 
on the system-data bus. 


lOWC 


l/0-write command, a signal generated by 
the master to indicate that the address of 
an output port has been placed on the 
system-address bus and that the contents 
of the system-data bus are to be output to 
the addressed port. 




Memory-read command, a signal generated 
by the master that indicates that the ad- 
dress of a memory location has been placed 
on the system-address bus. It specifies that 
the contents of the addressed location are 
to be read and placed on the system-data 
bus. 


MRDC 




Memory-write command, a signal gener- 
ated by the master to indicate that the 
address of a memory location has been 
placed on the system-address bus. It causes 
information on the data bus to be written 
into the addressed memory location. 


MWTC 


XACK 


Transfer-acknowledge signal, an input sig- 
nal to the master board from an external 
rhemory location or I/O port to indicate that 
a specified read or write operation has been 
completed. 
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80/lOA CPU board. 

The synchronous and asynchronous nature of the 
serial interface makes it compatible with virtually 
every standard serial data-transmission technique 
used today (including IBM's Bi-Sync). This allows 
multiple SBC-80 boards to be interconnected as a 
distributed-processing network. The resulting task 
segregation or redundancy (or both) significantly 
improves both system performance and reliability. 

Two jumper-selectable interrupt requests may be 
generated automatically by the serial interface. One 
occurs when a newly received character is ready to 
be loaded into the CPU (receive-channel buffer is full). 
The other occurs when new data are ready to be 
transmitted to the remote device (transmit-data buf- 
fer is empty). 

Both the SBC-80/04 and 80/05 provide serial I/O 
capability through the serial input data (SID) and 
serial output data (SOD) functions of the 8085 CPU. 
These functions are controlled by software executing 
the 8085 read-interrupt mask (RIM) and set-interrupt 
mask (SIM) instructions. 

For systems requiring many serial channels, the 
SBC-534 communications-expansion board provides 
four USART channels with RS-232-C and optically 
isolated current-loop interfaces, programmable inter- 
rupt, timing, baud-rate control, and a Bell 801 Auto- 
Call unit interface. 



Expand the system via the Multibus 

The SBC-80 family is gaining not only in popularity 
but in support for its Multibus as more and more 
companies offer SBC-compatible boards. Intel now 
provides high-speed mathematics, RAM, EPROM, 
mass storage, digital I/O, combination memory and 
I/O, serial communications, and analog- I/O expansion 
boards. 

For applications requiring fast, high-precision 
number crunching, the SBC-310 math unit acts as an 
intelligent slave to perform floating-point and fixed- 
point mathematics. A processor uses the 310 by 
passing parameters to it along with a command byte 
to select the desired operation from the SBC-310's 14 
instructions. The repertoire includes 32-bit floating- 
point (single-precision) addition, subtraction, multi- 
plication, division, squaring, square root, com- 
parisons, and tests; 16-bit fixed-point multiply, sub- 
tract, extended divide, and extended compare; and 
conversion from fixed to floating point or vice versa. 

A completed operation may be signaled either by 
the math unit via an interrupt or by the host 
processor's polling the "operation complete" flag in the 
unit's status register. The result may be retrieved at 
this point or left in the 310's accumulator for further 
use. 

In addition, the 310 provides control circuitry so that 
it may be treated as a "shared resource" among several 
CPU boards. 

Two diskette options are available for mass storage. 



Table 5. Programmable interrupt 
modes, SBC-80/20-4 



Mode 


Operation 


Fully nested 


Interrupt request line prior- 
ities fixed at as highest. 7 
as lowest. 


Autorotating 


Equal priority. Each level, af- 
ter 'receiving service, be- 
comes the lowest priority 
level until next interrupt oc- 
curs. 


Specific priority 


System software assigns low- 
est priority level. Priority of 
all other levels based in se- 
quence on this assignment. 


fuelled 


System software examines 
priority-encoded system in- 
terrupt status via interrupt 
status register. 



Table 6 




Line drivers and terminators 




Line drivers 


Driver 


— — ■ ■ 

Characteristic 


Sink current (mA) 


7438 
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48 


7437 




1 


48 


7432 




Nl 


16 


7426 




I.OC 


16 


7409 
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16 
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16 


7403 
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16 


7400 




1 


16 
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The SBC-201 diskette controller provides full control 
for one or two single-density diskette drives and acts 
as a programmable slave to masters on the Multibus. 
All diskette information is stored in the IBM soft- 
sectored format. For systems requiring greater 
storage capacity, the SBC-202 provides full control for 
up to four double-density diskette drives. Thus, 2 
Mbytes of mass storage may be added to SBC-80-based 
systems for each SBC-202 plugged into the bus. 

Digital I/O may be expanded using any of three Intel 
boards. The SBC-519 provides 72 programmable par- 
allel I/O lines as well as interrupt handling and a real- 
time clock. 

The 519's clock can interrupt the appropriate CPU 
periodically so that the CPU can monitor system-I/0 
status. High-speed I/O events can gain the CPU's 
attention via interrupts. The SBC-517 combination 
I/O board and the SBC-104, 108 and 116 combination 
memory and I/O boards offer 48 programmable par- 
allel lines, a full RS-232 USART serial channel, 
interrupt handling and a 16-ms real-time clock. The 
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Table 7. RMX-80 routine library 



RMX/80 module 


Function 


Nucleus (executive) 


Provides basic capabilities (concurrence, priority, and synchroniza- 
tion/communication) found in all real-time systems. 


Terminal handler 


Provides real-time asynchronous I/O between an operator's terminal and tasks 
running under the RMX/80 executive, includes a line-edit feature similar to 
that of ISIS-II (supervisory system on the Intellec development system) and 
type-ahead facility. 


Diskette file systems 


Diskette driver and file management capabilities, allows user to load tasks 
into the system and to create, access, and delete files in a real-time 
environment without disrupting normal processing. File formats compatible 
with ISIS-II for both single and double-density systems. 


Free space manager 


Maintains a pool of free RAM and allocates memory out of the pool upon 
request from a task; reclaims memory areas when no longer needed. 


Debugger 


Specifically designed for debugging software running under the RMX/80 
executive; used by linking it to an application program or task. Thus, it can 
be run directly from the single-board computer's memory. 


Math handler 


Provides full control and communication for SBC 310 math board for high- 
speed fixed and floating-point math functions. 


Analog interface handler 


Provides real-time control for SBC 711, 724, and 732 analog I/O expansion 
boards. 



104, 108 and 116 also hold up to 8 kbytes of EPROM, 
along with 4, 8 or 16 kbytes of RAM, respectively. 

For systems geared to especially noisy environ- 
ments, the SBC-556 provides 48 optically isolated I/O 
lines, which are configured as 24 input lines, 16 output 
lines, and eight programmable-I/0 lines. The user 
fixes the optical-isolation characteristics according to 
his exact system requirements by installing the opto- 
isolators and current-limiting resistors of his choice 
into the board sockets. Input voltages up to 48 V, 
output lines up to 30 V and currents up to 60 m A may 
be interfaced. 

Of course, many more RAM, ROM, communications 
and interface options are available. But for systems 
to come together quickly during development, there 
must be some standardized operating software to 
provide some of the most fundamental system rou- 
tines. 



System software: the glue that binds 

Where the Multibus provides a standard hardware 
structure, RMX-80, a real-time multitasking executive 
supplies a modular software framework. With 
RMX-80, routines don't have to be developed for task 
synchronization, priority resolution and peripheral 
control (printers, terminals, diskettes, etc.). Versions 



are available for the SBC-80/20, 80/20-4 and 80/lOA 
CPU boards. 

Critical projects can be completed rapidly because 
RMX-80 provides major portions of the software 
requirements for many real-time systems. For exam- 
ple, the diskette file-extension software of the RMX-80 
program may be linked into the system software. 
Thus, users can immediately have a diskette file 
structure with facilities to open and close files, create 
and delete files, read or write files sequentially or 
randomly (read function may be used for initial 
program load, if desired), or allocate file storage 
dynamically on single or double-density diskettes. 

The compactness of RMX-80— the entire executive 
resides in 2 kbytes of ROM— reduces memory require- 
ments and eliminates the need for bootstrap-program 
loading. All RMX-80 operations are based on individ- 
ual tasks. A task is a program with unique data and 
stack that operates asynchronously with other such 
programs in the system. 

Basically, the RMX-80 is a library of "standard" 
routines (Table 7), such as an analog-interface handler 
and a terminal handler. Fig. 4 illustrates how to 
develop software by selecting appropriate RMX-80 
modules, then locating and linking them with particu- 
lar software tasks on an Intellec microcomputer 
development system. In addition, a debugger module 
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5. This possible SBC-80 system configuration uses four 
SBC-80/05S to monitor and control pipeline parameters 



and feed data back to a master controller, an SBC-80/20-4. 
The master controller sends data back to a host system. 



in the RMX-80 speeds real-time system development. 
The executive accesses system resources according 
to task priority, intertask communication, interrupt- 
driven control for standard devices, real-time clock 
control, interrupt handling, and other optional func- 
tions. In all, there are 255 separate task-priority levels, 
and since multiple tasks may share the same level, 
the actual number of tasks is limited only by memory 



Develop programs with the Intellec 

The Intellec and its ICE-80 and ICE-85 in-circuit 
emulators help minimize the time required to develop 
software and hardware. Standard Intellec stand-alone 
software includes resident macroassemblers for the 
8080A and 8085 CPUs, a text editor, and a system 
monitor/debugger. As a result, programs can be 
assembled, loaded, edited, executed, and debugged. 

ICE diagnostics can significantly reduce program 
development and debug time. Break points may be 
set on user-specified memory-read or write opera- 
tions, I/O read or write operations, or user-defined 
extension parameters. Programs can be single-stepped 
to check operating conditions and performance. 

PL/M-80 is the high-level systems-programming 
language. The optional Intellec-resident PL/M com- 
piler provides the ability to program in this natural, 
algorithmic language, so there is no need to manage 
register usage or to allocate memory. PL/M programs 
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6. Expanding the pipeline monitor/controller system is as 

simple as plugging more cards into the Multibus and 
altering the software. By adding another SBC-80/20 to the 
master controller, some local processing can be done and 
a local CRT and high-speed printer can be added as well 
as RAM and diskette-memory space. 

may be linked to assembly-language programs to 
hasten product development further. 

A relocatable macroassembler residing on the In- 
tellec translates symbolic assembly language into 8080 
or 8085 machine code and permits the use of re- 
locatable and linkable object code. With full macro 
capability, similar sections of code needn't be written 
over and over. 

Intellec options include a diskette operating system, 
ISIS-II, with diskette controller, single or dual diskette 



drives and ISIS-II software. ISIS-II provides all the 
facilities for producing and handling relocatable code, 
including a relocating macroassembler, relocating 
loader and a linker to help link separately compiled 
or assembled programs. 



Apply the SBC boards to real use 

To get an idea of the SBC 80 family's capabilities, 
examine the application shown in Fig. 5. In this case, 
a remote control/monitoring section of a pipeline 
supervisory control system grows with increasing 
requirements for additional local throughput and 
processing capability. 

Four SBC-80/05s act as remote pipeline 
monitors/controllers. Each unit monitors various con- 
tact closures (limit switches, relays, etc.) and a hex 
keypad, with a subset of its own I/O lines programmed 
as inputs. Contact debounce is performed in software. 
Other digital I/O lines on each SBC-80/05 act as output 
lines to drive a numeric display and various control 
relay coils. 

Analog-control lines are interfaced with an SBC-732 
combination analog-I/0 board. Transducers indicat- 
ing temperature and pressure drive analog inputs, and 
analog outputs drive valves. Flow rate is determined 
in software by manipulating differential pressure 
data available from pressure transducers. 

The four 80/05s are linked serially to a remote 



SBC-80/20-4-based data concentrator. An SBC-534 
communications expansion board provides four 
RS-232-C serial channels, each interfacing directly 
with one of the four 80/05-based pipeline 
monitor/controllers. The 80/20-4 periodically queries 
each monitor to determine its current status. The 
concentrator also relays control commands from a 
host computer controlling the entire pipeline. The 
80/20-4's own RS-232-C serial channel provides the 
interface for this high-speed synchronous link to the 
host CPU. 

The 80/20-4 can contact the host CPU with the Bell 
801 automatic calling-unit interface on the SBC-534. 
The synchronization and control of communication 
between the four 80/05s and the host are handled by 
RMX-80 on the 80/20-4. 

The 80/20-4 system can be expanded to provide local 
processing capability, as shown in Fig. 6. Here, anoth- 
er 80/20 is added as a second master on the Multi- 
bus to provide control for a local CRT and high- 
speed printer, and to provide local processing 
capability. 

An additional 32 kbytes of RAM are furnished by 
an SBC-032 RAM-expansion board. A third master, 
an SBC-202 dual-density diskette controller, can also 
be added to the Multibus, along with two double- 
density diskette drives. Communication between the 
two 80/20s is handled via user-written intermaster 
message tasks. ■■ 
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DESIGN MOTIVATIONS 

FOR MULTIPLE PROCESSOR 

MICROCOMPUTER SYSTEMS 



Design decision factors involved in developing multiple processor 
microcomputer systems include means of minimizing contention for 
system bus utilization. System applications detail the appropriate 
hardware and software considerations as related to single-board 
computers in a multimaster bus structure 



George Adams and Thomas Rolander Intel Corporation, Santa Clara, California 



■■■arge-scale integrated circuit technology has reduced 
the cost of central processors to such a low level that 
the previously avoided concept of applying multiple 
processors to meet system performance requirements has 
now become an attractive and viable alternative. Several 
key benefits accrue from such an approach. In addition 
to enhanced system performance (throughput), improved 
system reliability, and improved system realtime re- 
sponse, modular system expansion capabilities may be 
realized. Although designing such systems "from 
scratch" with microprocessor component families can 
be a complex system design task with many subtle pit- 
falls which can inhibit efficient system operation, the 
advent of second generation single-board computers, 
such as the Intel® SBC 80/05 and 80/20, has allowed 
multiple processor microcomputer systems to become 
off-the-shelf products. 



Motivation and Design Concepts 

Discussion of the benefits of multiple processor structures 
in system applications will provide an understanding of 
the motivation for this implementation approach in sys- 
tem design. A primary objective addressed through 



multiple processor approaches is enhanced system per- 
formance and throughput. Enhanced performance is 
achieved through partitioning of overall system functions 
into tasks that each of several processors can handle 
individually. 

In general, as the number of individual tasks any 
given processor must handle is reduced, that processor's 
response time to new requests for service will be reduced. 
A well planned multiple processor bus structure will 
allow new processors to be added to the system in 
modular fashion. When new system functions (ie, more 
peripherals) are added, more processing power can be 
applied to handle them without impacting existing pro- 
cessor (master) task partitioning. 

As used here, a "master" is any element existing on the 
system bus that may take control of the bus (ie, assert 
address and control lines). Typical examples include 
processors and direct memory access (dma) controllers 
that address memory and input/output (l/o) locations 
resident on the bus. "Slave" elements include passive 
functions on the bus, such as memory or non-DMA l/o 
interfaces. Note that although slaves may possess intelli- 
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Fig 1 Multiple processor bus structure. Dual onboard/offboard structure of MULTIBUS allows each master to use its 
own memory and I/O without utilizing common system bus (a). Only when a master requires access to common mem- 
ory or I/O does it use the bus (b). Note that other masters may continue onboard operations simultaneously 
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Fig 2 SBC 80/05 block diagram. 
SBC 80/05 is a full microcom- 
puter on a single PC board. It 
provides 8085 CPU plus RAM for 
program or data storage, EPROM/ 
ROM for program storage, inter- 
val timer, programmable parallel 
I/O (22 lines), serial I/O, and 
full MULTIBUS multimaster con- 
trol logic 
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gence (eg, an onboard processor), they are not bus 
"masters" unless they can control the system bus. 

Hardware Considerations 

Hardware considerations must be thoroughly evaluated 
in any multiple processor bus structure. These factors 
are described in detail around a specific implementation 
of such a structure, the Intel" multibus'^^, which sup- 
ports multiple processor systems with its multi-master 
bus structure. 

Bus Architecture 

One architectural option open to the system designer is 
that of a multiple master/single bus structure. Under 
this partitioning, every master utilizes the common bus 
data path to fetch instructions or data from memory, 
read data from input devices, or write data to output 
devices or memory. Therefore, the common system bus 
rapidly becomes the bottleneck for overall system 
throughput, and fast DMA transfers can easily approach 
the full bandwidth of the bus during block transfers so 
that all other masters must idle for extended periods. 



Such performance constraints can severely limit total 
system performance. 

System bus utilization may be minimized through 
implementation of an alternate dual-bus structure as 
shown in Fig 1. Each processor-based master within the 
system retains its own local memory and l/o that it 
utilizes for most operations. Such local operations occur 
totally on the individual board and do not require the 
system bus. This greatly reduces the service request 
frequency by each master requiring use of the system bus. 
Such a dual-bus structure is implemented on the SBC 
80/05 and 80/20 single-board computers, as shown in 
Figs 2 and 3, respectively, with the multi-master system 
bus (multibus). ^'2 

Access to the system bus is requested only when a 
global (resident on the bus and accessible by multiple 
masters) memory location or l/o device is referenced 
during an instruction execution cycle. Local/global (on- 
board/offboard) distinction is defined through the value 
of the physical address referenced. If it lies within the 
address range of onboard memory or i/o, no bus request 
is made. Only when the address references a global 



Intel® and multibus"^" are trademarks of Intel Corp, Santa Clara, 
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Fig 3 SBC 80/20-4 block diagram. SBC 80/20-4, also a full microcomputer on a single PC board, provides 8080A-2 CPU, 
4k bytes of RAM, up to 8k bytes of EPROM/ROM, 48 programmable I/O lines, three interval timers, full RS-232-C serial 
port, 8-level priority interrupt logic, and MULTIBUS multimaster control logic 
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memory or l/o location, is a system bus request initiated. 
If no other master is currently utilizing the bus, this 
"new" master will be granted access immediately. How- 
ever, this new master must wait if another master is 
currently utilizing the system bus. It continues to monitor 
the status of the system bus to determine when its cur- 
rent cycle may be completed. Thus, the MULTIBUS must 
provide a method for masters to determine whether or 
not another master is currently utilizing it. 

Other masters may also simultaneously request the 
system bus. Arbitration must then be performed to re- 
solve this multiple contention for the system bus. The 
MULTIBUS structure provides this arbitration in one of 
two techniques: serial (daisy chain) or parallel (en- 
coded). The structure consists of four control lines that 
are synchronized by the common bus clock. These four 
control lines and the bus clock are active low. This is 
represented by the slash (/) character after each signal 
mnemonic. Control lines are as follows: 

Bus Clock (BCLK/) —The negative edge of BCLK/ is 
used to synchronize bus arbitration. BCLK/ may be asyn- 
chronous to all CPU clocks, and it has a 100-ns minimum 
period. BCLK/ may be slowed, stopped, or single- 
stepped for debugging. 

Bus Priority In Signal (BPRN/)— Indicates to a par- 
ticular master that no higher priority master is request- 
ing use of the system bus. 

Bus Priority Out Signal (BPRO/) — Used with serial bus 
priority resolution scheme. BPRO/ is passed to BPRN/ 
input of master with next lower bus priority. 

Bus Busy Signal (BUSY/) — Driven by bus master cur- 
rently in control of multibus to indicate that bus is 
currently in use. BUSY/prevents all other masters from 
gaining control of bus. 

Bus Request Signal (BREQ/) — Used with parallel bus 
priority network to indicate that a particular master re- 
quires use of the bus for one or more data transfers. 



Serial (Daisy-Chain) Bus Arbi+ra+ion 

In a serially arbitrated multibus system (Fig 4) re- 
quests for system bus utilization are ordered by priority 
on the basis of bus location. Each master on the bus 
notifies the next lower priority master when it needs to 
use the bus for a data transfer, and it monitors the bus 
request status of the next higher priority master. Thus 
the masters pass bus requests along from one to the next 
in a daisy-chain fashion. 

The highest priority master (Master 1) in the system 
will always receive access to the system bus when it 
requires it. There is no higher priority master to inhibit 
its bus requests, and its bus priority input line (BPRN/) 
is thus permanently enabled. 

Masters operate asynchronously on the multibus. A 
master may thus be in the middle of a bus operation 
when a higher priority master requests the bus. Ob- 
viously, interruption of such an in-process cycle must 
not be allowed. The mechanism for avoiding such 
erroneous operation is the BUSY/ line. Upon being 
notified that access to the bus is possible, the master 
examines BUSY/. If this control line is inactive, the 
master will assert it, and complete its bus operation. 
If BUSY/ is already active, another master is currently 
using the bus. In this case, the master will examine 
BUSY/ upon every falling edge of BCLK/, typically 
once every 100 ns, until it becomes inactive. When 
BUSY/returns to its inactive state, the master will assert 
it, then complete its operation. The BUSY/line then in- 
hibits higher priority masters from destroying a bus 
transfer cycle that may be already in progress. 

The BUSY/ line is also controlled by a bus lock 
function on the SBC 80/05 and 80/20. This function 
allows a master, which currently has control of the bus, 
to retain control by independently asserting the BUSY/ 
line until it issues an unlock command that releases 
BUSY/. This permits a bus master to obtain exclusive 
control of the system bus for critical system functions. 
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Fig 4 Serial bus arbitration. When any master 
requires use of MULTIBUS in serial (daisy-chain) 
priority mode, its BPRO/ line inhibits lower prior- 
ity masters from system bus utilization. BUSY/ 
line is used to ensure that in-process operations 
of lower priority masters are not destroyed by 
asynchronous bus requests of higher priority 
masters 
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such as high speed memory or l/o data transfers and 
critical read-modify-write operations. With BUSY/ 
asserted in this way, all other masters will find the bus 
"in use" when they attempt to access it. Whereas system 
bus transfers normally take place on an interleaved basis 
(bus arbitration performed for each cycle), this bus 
lock function permits fast multiple-word transfers, when 
needed. 

Two basic parameters determine the number of masters 
that can coexist on the system bus in serial bus arbitra- 
tion mode. These are the BCLK/ cycle time and the 
BPRN/ to BPRO/ propagation delay of bus masters. 
Masters may be added to a system as long as the cumula- 
tive BPRN/ to BPRO/ propagation delay is such that the 
lowest priority master will always have its BPRN/ line 
driven inactive before the next BCLK/ falling edge after 
the highest priority master requests the bus. This worst- 
case timing condition is met as long as the following 
relationship is satisfied. 

N-1 ' 
whi 



o) 1 < t„ 



ere 



(tni'RN-RiRo) 1 = Propagation delay for master i 
tnct.K = Bus clock (BCLK) cycle time (period) 
tsh = Allowance for bus setup and hold times 
N = Number of bus masters 

Using serial bus arbitration and SBC 80 onboard 
clocks, up to three masters may coexist on the system 
bus. This number can easily be extended, if desired, by 
generating a BCLK with a longer cycle. The SBC 80/05 
and 80/20 provide a jumper option which allows the 
onboard BCLK/ to be disabled. This allows the system 
designer to generate BCLK/ externally. 

Parallel (Hardware-Encoded) Bus Arbitration 

The parallel bus arbitration technique resolves system 
bus master priorities using external hardware. The 



parallel multimaster control line (BREQ/) comes into 
force in this case. Each master asserts BREQ/ when it 
requires access to the system bus. These lines are fed 
to a 2-chip parallel priority network. As with serial 
priority resolution, BPRN/ acts as the bus access enable 
input to each master. As Fig 5 illustrates, up to eight 
master priority levels are encoded by a 74148 priority 
encoder to a 3-bit code representing the highest priority 
master currently requesting the system bus. This code 
drives the 8205 3-to-8 decoder which asserts the proper 
BPRN/ line low to grant bus access to the highest 
priority master. The 74148/8205 propagation delay is 
less than 40 ns, easily fast enough to allow eight masters 
to coexist in this configuration utilizing a BCLK/ with 
a 100-ns period. 

Systems requiring up to 16 masters may implement bus 
arbitration by utilizing two 74148 priority encoders and 
two 8205 decoders to provide a 16-level hardware pri- 
ority network. The actual number of bus masters feasible 
on the system bus will also depend on bus drive/loading 
considerations. Even under this consideration, systems 
containing up to 16 masters are feasible. 

Thus, single-board computer masters, in conjunction 
with the MULTIBUS control structure, provide off-the-shelf 
hardware solutions for the development of efficient multi- 
ple processor microcomputer systems. In addition to this 
hardware capability, the system designer needs to con- 
sider several software design issues. 



Software Considerations 

Several software operations, such as mutual exclusion, 
communication, and synchronization, are essential to 
proper multiple processor system operation. The 
MULTIBUS/SBC 80 functions that enable these software 
operations are examined. 

Mutual Exclusion 

In a multiple processor microcomputer system, there are 
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Fig 5 Parallel bus arbitration. Under parallel bus 
arbitration structure, multiple requests for access to 
the MULTIBUS are determined by 2-chip hardware 
priority network. When simultaneous multiple bus re- 
quests occur, only highest priority master has Its bus 
grant (BPRN/) line asserted. BUSY/ line inhibits other 
masters from interfering with system bus cycles in 
progress 
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usually many resources that are shared by the processors. 
Such shared resources include common memory and 
peripherals. A properly functioning system must provide 
a mechanism to guarantee that asynchronous access to 
those resources is controlled in order to protect data 
from simultaneous change by two or more processors. 
Thiis, some form of mutual exclusion must be provided 
to enable one processor to lock out access of a shared 
resource by other processors when it is in a critical 
section. A critical section is a code segment that once 
begun must complete execution before it, or another 
critical section that accesses the same shared resource, 
can be executed. 

A Boolean variable can be used to indicate whether 
a processor is currently in a particular critical section 
(true) or not (false). Testing and setting this variable 
also presents a critical section. This function must be 
performed as a single indivisible operation; if it is not, 
two or more processors may test the variable simul- 
taneously and then each set it, allowing them to enter 
the critical section at the same time. Such simultaneous 
entry would destroy the integrity of data and control 
parameters in global memory or cause erroneous double 
initialization of a global peripheral controller. 

Mutual exclusion can be implemented as a software 
function alone, as described by Dijkstra'*, for n proces- 
sors operating in parallel. The SBC 80/05 and 80/20 
bus lock function mentioned earlier provides a means 
for using program control to simplify mutual exclusion. 
While the system bus is locked, the master can perform 
the indivisible test and set operation on the Boolean 



variable used to control access to a critical section with- 
out intervention from other masters. 

Communication 

Communication is an essential function that allows a 
program executing on one processor to send or receive 
data from a program executing on another processor. 
Typically, two processors communicate through buffer 
storage in common memory. One program, called a 
producer, adds data to buffer storage; another, called a 
consumer, removes information from buffer storage. 

In a typical application, one master may produce 
buffers of data that are to be consumed by a program 
executing on another master that services an output 
device. Communication through buffer storage requires 
the operations of adding to and taking from buffers. 
These operations constitute critical sections that can be 
controlled by providing mutual exclusion around the 
buffer manipulation operations. 

Synchronization 

At times there is a need for one master to send a syn- 
chronization signal to another. In a sense, synchronization 
is a special case of communication during which no 
data is transferred. Rather, the act of signaling is used 
to "wake up" a program executing on another master. 
A program may "sleep," by waiting for a synchronizing 
signal, until it receives a wake-up signal that enables 
it to continue execution. Manipulation of synchronization 
signals requires mutual exclusion. 
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Fig 6 Multiple processor 
communication application. 
Multiple processors may be 
utilized to increase throughput 
in system requiring several 
high speed serial channels. 
SBC 80/05 single-board com- 
puter controls four RS-232-C 
or 20-mA serial channels in- 
terfaced to system through 
SBC 534 communication ex- 
pansion board. Second single 
board computer (SBC 80/20) 
retrieves data records con- 
structed by SBC 80/05 and 
performs further processing 
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System Initialization 

In a microcomputer system that has multiple processors 
sharing a common system bus, a system initialization 
mechanism must be designed to set up the variables that 
control access to the shared resources. All single-board 
computers on the multibus begin execution simulta- 
neously following a system reset. The bus lock function 
of the computers can be used by one specifically desig- 
nated master to lock the bus immediately upon system 
reset and to perform system initialization for common 
resources before any other master attempts to access 
them. Since a locked bus has no effect on a single-board 
computer that is executing out of its local memory and 
using its local l/o, normal initialization by each processor 
can proceed while the shared resource initialization takes 
place. 



Multiprocessor 
Applications 

Two applications that are well suited to multiple pro- 
cessor microcomputer systems are examined. The first 
provides increased throughput, and the second allows 
shared resources. 

Increased Throughput 

Consider a system that is controlling multiple high speed 



serial communication channels in addition to other data 
processing activities. In this case, multiple processors 
may be utilized to increase system throughput. Such a 
system with four full-duplex serial channels operating 
at 4800 baud could produce interrupts every 250 fxs. 
Interrupts at that frequency in a single master system 
would leave little time for other processing activities. 
In a multiple processor approach, one processor can be 
used to handle the interrupts from the serial channels, 
accumulate data into records, and then provide those 
records to another processor by placing them in com- 
mon memory. The second processor is not burdened 
with the overhead of handling each character on an 
interrupt-driven basis, instead it is sent entire records 
of data available for further processing. 

As shown in Fig 6, this application can be handled 
on the MULTIBUS with four boards. The SBC 80/05 
single-board computer is used to service the communi- 
cation board and prepare the data records. A 4-channel 
serial communication board (SBC 534) is used to pro- 
vide the hardware interface for four serial communica- 
tion channels. The SBC 80/20 single-board computer is 
used to process data records prepared by the SBC 80/05. 
Common memory is provided by the SBC 016 16k 
random-access memory (ram). 

Application of multiple processors to this problem 
requires communication through buffer storage. Two 
primitive operations, introduced by Dijkstra*, can be 
used to simplify the communication and synchronization 
between the masters. These primitives, designated P and 
V, operate on non-negative integer variables called 
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Fig 7 Multiple processor 
shared-resource applica- 
tion. MULTIBUS multiple 
processor structure allows 
two independent single- 
board confiputers to share 
common system resource, 
such as an SBC 310 high 
speed math board, to per- 
form floating point opera- 
tions 
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semaphores. The V procedure increments the sema- 
phore (S) in a single indivisible operation. To make 
certain that fetch, increment, and store are not inter- 
rupted by another processor, the bus is locked during 
the operation. 

Procedures for P and V primitive operations can be 
implemented in pl/m^ as follows: 



/* Lock Ml^l.TIBUS •/ 

/• Intrenifnt semaphore •/ 
/• Unlock MULTIBUS */ 



PROCEDURE (S$ADR): 
DECLARE S BASED S$ADR BYTE; 

OUTPUT(BUSJLOCK) = LOCK; 

S = S+1; 

OUTPUT(BUS$LOCK) = UNLOCK; 
ENDV; 

The P procedure loops in a busy wait until S is greater 
than zero, at which time it decrements S. The act of 
fetching, testing, decrementing, and storing S is also an 
indivisible operation. Note that if several masters with 
different speeds are in a busy wait on the same sema- 
phore, the solution presented may not be "fair" to the 
lower speed processor; that is, the lower speed processor 
would test the semaphore less frequently, resulting in 
an unfair advantage for higher speed processors. 

Implementation of a procedure for the P primitive is 
shown in the following pl/m code. 



CONSUMER: 




DECLARE EMPTY BYTE EXTERNAL; 


/• Number of empty buffers •/ 


FULL BYTE EXTERNAL; 


/• Number of full buffers •/ 


SEMA BYTE EXTERNAL; 


/• Binary semaphore ♦/ 


OUTPUT(BUS$LOCK) = LOCK; 


/• Lock MULTIBUS •/ 


EMPTY = NUMBIBUFFERS; 


/* Initialize semaphores •/ 


FULL = 0; 




SEMA = 1; 




OUTPUT! BUSILOCK) =^ UNLOCK; 


/* Unlock MULTIBUS •/ 


DO FOREVER; 




CALL P( FULL); 


/• Decrement full buffer */ 


CALLP(SEMA); 


/* semaphore */ 




/* Decrement mutual exclusion */ 




/• semaphore •/ 


(Take data from buffer and 




place it in local memory, 




move liuiTcr from full to 




empty linked list) 




CALL V( SEMA); 


/• Increment mutual exclusion */ 


CALL V( EMPTY): 


/• semaphore •/ 




/• Increment empty buffer ♦/ 




/* semaphore */ 


(Process the data) 




END; 




KND CONSUMER; 





PRODUCER: 

DECLARE (EMPTY, FULL, SEMA) BYTE EXTERNAL; 
DO FOREVER; 



P: 




(Prepare data in local 




PROCEDURE (S$ADR); 
DECLARE S BASED SJADR BYTE; 




memory) 




DO FOREVER: 








IFS > OTHEN 
DO; 

OUTPUT{BUS$LOCK) = LOCK; 
IF S > THEN 
-DO; 


/* Test semaphore •/ 

/• Lock MULTIBUS */ 
/• Relest semaphore */ 


CALL P( EMPTY); 
CALL P(SEMA); 


/* Decrement empty buffer semaphore ♦/ 
/* Decrement mutual exclusion */ 
/* semaphore */ 


S = S-1; 

OUTPUT(BUS$LOCK) = UNLOCK; 

RETURN; 

END; 


/• Decrement semaphore */ 

/• Unlock MULTIBUS */ 

/• Exit from P procedure •/ 


(Place data in a buffer, 
move buffer from empty 
to full linked list) 




01JTPUT(BUS$L0CK) = UNLOCK; 
END; 


/• Unlock MIILTIBUS •/ 

/* and continue testing */ 






END; 
ENDP; 




CALL V( SEMA); 
CALL V(FULL); 


/* Increment mutual exclusion */ 

/• semaphore */ 

/♦ Increment full buffer semaphore */ 


It is important to observe in the program listing that S 


END; 
END PRODUCER; 





is tested prior to issuing a bus lock. This initial test 
avoids continuous locking and unlocking of the system 
bus while looping in a busy wait. The second test is 
required because another processor could also have found 
S greater than zero and tried to enter the critical section 
at the same time. 

With the P and V operations, semaphores can be used 
as resource counters in the buffer manipulation required 
for communication between the SBC 80/05 and 80/20. 
For example, a consumer program can use the P oper- 
ation to decrement the number of full buffers and a V 
operation to increment the number of empty buffers. 
In a similar fashion, a producer program can use the 
P operation to decrement the number of empty buffers 
and a V operation to increment the number of full 
buffers. In addition to full and empty buffer counters, 
it is necessary to maintain linked lists pointing to actual 
full and empty buffers. A semaphore can be used to 
provide mutual exclusion around the manipulation of 
the linked lists. In the example that follows, three 
variables (full, empty, and sema) are used to imple- 
ment these functions. The two pl/m programs illustrate 
consumer and producer code segments, respectively. 
Note that the consumer performs initialization because 
it accesses the semaphores prior to the producer. 



Shared Resources 

Another typical application for a multiple processor 
microcomputer system would be to allow sharing of a 
resource by two processors. For example, consider two 
independent processors that have a need for high speed 
mathematical functions. Although it may not be possible 
to justify a high speed math module for each system, 
such a module might be justified if it were to be shared 
by both processors. A multiple processor microcomputer 
system could provide the capability to allow both pro- 
cessors to share the math module and not interfere with 
their otherwise unrelated functions. 

This application (illustrated in Fig 7) could be 
handled with four boards. The SBC 80/05 single-board 
computer is used to perform various data processing 
functions requiring high speed floating-point arithmetic. 
The SBC 80/20 single-board computer controls a process 
where high speed numeric computations are required. 
High speed floating-point mathematics functions for 
both single-board computers are performed by an SBC 
310 high speed math unit. SBC 116 combination memory 
and i/o board provides 16k RAM, 8k electrically pro- 
grammable read-only memory (eprom), 48 parallel 
i/o lines, and an RS-232-C serial port. 
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The problem to be solved in this application is to 
ensure that only one processor has access to the shared 
math module resource at one time. Thus, mutual ex- 
clusion must be provided to control the access to the 
resource. The following pl/m function returns TRUE 
if access to a critical section, used to implement the 
mutual exclusion, has been granted. 



ENTERJCRITICAUSECTION : 




PROCEDURE (FLAGIADR) BYTE; 




DECLARE FLAG BASED FLAG$ADR BYTE; 




DECLARE ACCESS BYTE; 




IF FLAG = BUSY THEN 


/• Test flag •/ 


RETURN FALSE; 


/♦ Return false if busy •/ 


ACCESS = FALSE; 




OUTPUT (BUSILOCK) = LOCK; 


/♦ Lock MULTIBUS •/ 


IF FLAG = NOT BUSY THEN 
DO; 

FLAG = BUSY; 


/♦ Relest flag */ 


/♦ Set flag busy ♦/ 


ACCESS = TRUE; 


/♦ and access true */ 


END; 




OUTPUT (BUSILOCK) = UNLOCK; 


/• Unlock MULTIBUS •/ 


RETURN ACCESS; 


/• Return either true or */ 




/• FALSE access •/ 



END ENTER$CRITICAL»SECTION; 

This pl/m function first tests the flag for the busy 
condition before issuing a busy lock. As in the P pro- 
cedure described earlier, this initial test avoids con- 
tinuous locking and unlocking of the multibus while a 
busy wait is being executed. The following procedure 
performs a busy wait operation on the flag used to 
control access to a critical section. 



BUSYIWAIT: 

PROCEDURE (FLAGIADR) ; 

DO WHILE NOT ENTERICRITICALISECTION (FLAGIADR) ; 

END; 
END BUSYIWAIT; 

Typical code segments illustrating the use of these pro- 
cedures follow. 

DECLARE MATHIBDIFLAG BOOLEAN EXTERNAL; /• Flag must be ♦/ 

/* initialized */ 
MATHIBDIFLAG = NOT BUSY; 



CALL BUSYIWAIT (.MATHIBDIFLAG) ; 



(Process math functions) 



MATHIBDIFLAG = NOT BUSY; 



/* Here we wait until */ 
/♦ we have access */ 



/* Set flag not busy */ 



/* We could also test and then do some other */ 

/• processing if the math module is busy */ 

IF ENTERICRITICALISECTION (.MATHIBDIFLAG) 

THEN DO; 



(Process math functions) 



and throughput. When the appropriate hardware/soft- 
ware design considerations are made, modularity is 
easily achieved. Hardware solutions to many problems 
are provided by means of a multibus structure and 
SBC 80 single-board computers that have multimaster 
capability. Through control of multibus functions, the 
software designer can perform multiple processor com- 
munication, synchronization, and mutual exclusion. 

Even with these significant steps toward the simplifi- 
cation of multiple processor microcomputer systems, the 
design of such systems remains a complex software/ 
hardware design task. The future trend of multiple 
processor microcomputer systems will be to simplify the 
software tasks of implementing communications, syn- 
chronization, and mutual exclusion. These functions 
could be performed in varying degrees by additional 
hardware bus functions. 

Potential rewards for a multiple processor architecture 
include enhanced system throughput, improved real-time 
response, modular system expansion, and improved sys- 
tem reliability. These benefits will pressure the tech- 
nology of parallel processing to include microcomputers 
in an increasing number of computer applications. 



References 

1. "SBC 80/05 Hardware Reference Manual," Pub 9800463, 
Intel Corp, Santa Clara, Calif, 1977 

2. "SBC 80/20 Hardware Reference Manual," Pub 9800317, 
Intel Corp, Santa Clara, Calif, 1976 

3. A. C. Shaw, The Logical Design of Operating Systems, Pren- 
tice-Hall, Englewood Cliffs, NJ, 1974, pp 59-78 

4. E. W. Dijkstra, "Solution of a Problem in Concurrent Pro- 
gramming Control," Communications of the ACM, Sept 1965, 
p569 

5. "Intel MULTIBUS Interfacing," Pub AP-28, Intel Corp, Santa 
Clara, Calif, 1977 

6. D. McCracken, A Guide to PL/M Programming for Micro- 
computer Applications, Addison- Wesley, Reading, Mass, 1978 



MATHIBDIFLAG = NOT BUSY; 
END; 
ELSE DO; 



/* Set flag not busy */ 



(Something else) 



Conclusions 

The motivations for implementing multiple processor 
microcomputer systems include enhanced performance 
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Technology 



Triple-bus architecture lets a 

single-board microcomputer's CPU operate at full speed 
while other system components share the main memory. 




The introduction of Intel's iSBC 80/30 marks the 
beginning of the third generation of single board 
computer architecture. Two features separate the new 
microcomputer from second-generation single-board 
/iCs. The major one is a triple-bus architecture that 
supports a dual-port memory. As a result, the on- 
board CPU does not tie up the main system bus (Intel's 
Multibus) when using the memory. Moreover, with 
two ports, the memory becomes a global resource, 
accessible via the three buses from the on-board 8085A 
CPU as well as from remote CPUs and other external 
devices in multimaster schemes. 

In addition, the 80/30 contains two microprocessors: 
an 8085A acting as the master CPU and an 8041 single- 
chip microprocessor acting as a slave, or intelligent- 
I/O, processor. 



Jim Johnson, Project Leader, Craig Kinnie, Project Man- 
ager, and Mike Maerz, Marketing Manager, Intel Corp., 
Santa Clara, CA 95051. 



To appreciate the benefits of the 80/30's triple-bus, 
dual-port memory architecture, examine the following 
problem. Now that fully one fourth (16-kbytes) of the 
available memory space in a 64-kbyte iiC system can 
reside on a single-board fiC, the CPU must share these 
16-kbytes with other system components, such as 
direct-memory-access devices, discs and other proces- 
sors. What's the best solution— especially when, in 
many applications, 16-kbytes is all the memory that's 
required by the whole system? 

Alternatives have problems 

The most straightforward way is a split-bus 
architecture, in which both the CPU and the system 
have equal access to the memory (Fig. la). While the 
system bus will be able to handle memory access 
efficiently from devices tied to it, it will be tied up 
by the CPU— so external operations not related to 
memory accesses will be hindered. 



Reprinted by Permission: Electronic Design, 1978. 
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1. Microcomputer-bus organizations takes several forms: 
In a split-bus approach (a) the CPU and system have equal 
access to memory, but the CPU ties up the system bus; 
in a single-bus (b), the CPU encounters extra delays in 
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using the system bus. A dual-bus structure (c) also has 
buffer delays, and no system access to on-board memory. 
But a triple-bus (d) avoids all these problems, allowing 
total system access to memory. 



A single-bus approach (Fig. lb) is hampered by 
buffer and bus-intervention delays which limit the 
CPU's performance. And dual-bus architecture (Fig. 
Ic), while granting the CPU exclusive access, does not 
allow other bus masters access to the memory. Also 
dual-bus suffers from buffer delays. 

A triple-bus, dual-port architecture (Fig. Id) pro- 
vides the benefit of both single and dual-bus architec- 
tures: total system access and exclusive access by the 
CPU. But it also has its disadvantages: Dual-port 
architecture requires many buffers as well as access- 
arbitration logic. However, 20-pin octal buffers in- 
troduced by several manufacturers don't take up 
nearly as much board space or cost as much as 
equivalent standard buffers. Since the octal buffers 
come in unidirectional or bidirectional forms— and at 
nearly the same cost— the three-bus approach used 
on the 80/30 actually takes only as many packages 
as the split-bus approach. 

Access arbitration is solved in the 80/30 with cycle 
status signals from the 8085A CPU. Instead of provid- 
ing equal access to the RAM from both the CPU and 
the system, the arbitration logic is designed to favor 
the CPU. By assigning the default state of the arbiter 



to the CPU, the logic anticipates a CPU memory access 
and reserves the memory until the cycle is complete. 

In addition, if an on-board CPU access is imminent, 
a reservation signal derived from the 8085A CPU 
status signals, the ALE (address latch enable), the 
address, and the cycle status signals (SO, SI, lO/M) 
will hold off bus contention. As a result, the CPU can 
operate at full speed without tying up the system bus. 

Of course, this extra CPU performance cuts into the 
rest of the system's memory-access time. However, 
the penalty imposed by the arbiter is less than 200 
ns— less than the time it would take a DMA device 
to regain control of the bus in the split-bus approach, 
where access must be interleaved. 

A bus hierarchy 

The three buses in the 80/30 hierarchy (Fig. 2) are 
an on-board bus, a dual-port (DP) bus and the Multi- 
bus (system bus). Innermost is the on-board bus, 
which connects the 8085A, all on-board I/O peripher- 
als and ROM. The next bus in the hierarchy, the dual- 
port connects a dual-port controller, 16-kbytes of 
dynamic RAM and a dynamic RAM controller. The 
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2. The full 80/30 one-board microcomputer is organized 
around its three buses: on board, dual-port, and the 
external-system Multibus. The main CPU, an 8085A, runs 



at 2.76 MHz, while an 8041A one-chip microprocessor 
serves as a peripheral controller or slave processor, 
running with a 2.6-ms cycle time. 
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3. The microcomputer's on-board memory may be ad- 
dressed independently by the on-board central processor 
and Multibus bus masters to increase the efficiency of 
usage of the total available memory space. 



outermost bus, the Multibus, offers modules that 
permit either the expansion or addition of system 
resources. 

With the on-board bus, the 8085A communicates 
with its on-board I/O and ROM (or PROM, if desirable) 
and the dual-port bus. Since the on-board bus permits 
access to the I/O and ROM only from the 8085A, all 
I/O and ROM (up to 8-kbytes are the 8085A's private 
property). And as a result, the 80/30 can operate on 
its on-board bus while another Multibus master uses 
the Multibus, accessing data from the board's dual- 
port RAM without reducing processor speed. 

The dual-port (DP) bus contains 16-k of read/write 
memory, implemented with Intel's 2117 16-kbyte 
dynamic RAM and the 8202 dynamic RAM controller 
(DRC). The DRC interfaces the DP bus to the 16- 
kbytes of dynamic RAM, and provides an almost 
static-RAM type interface. It provides the system with 
multiplexed addresses, address strobes, and refresh 
control to the RAM, as well as refresh/access arbi- 
tration and acknowledges. 

The RAM on this bus can be accessed from either 
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the 8085A on the 80/30 or the Multibus. The DP 
controller arbitrates the RAM requests and performs 
the bus exchanges. 

The DP controller always leaves the DP bus under 
the control of the 8085A when it is not in use. This 
permits the 8085A to operate at maximum processor 
speed when controlling the bus, since there isn't any 
bus-exchange overhead. When the Multibus requests 
access to the DP RAM, the DP controller transfers 
control of the DP bus to the multibus, as soon as the 
DP bus is not busy. Once the Multibus transfer is 
complete, the DP bus is returned to the 8085A. 



The 80/30 in brief 







Multiple communication 

The DP controller has two independent address 
decoders— one for decoding Multibus requests, the 
other for 80/30 requests. This not only permits the 
address space of the memory to be located in two 
different parts of memory (Fig. 3), it enables several 
80/30s to talk to each other over the Multibus, while 
sharing the same on-board address as seen by the 
8085A. Thus, one program can be loaded in any 80/30 
without relinking and relocating the software for 
execution. 

Each bus can communicate either within itself, or 
with the adjacent bus. Thus, the on-board bus cannot 
communicate directly with the multibus. However, 
when the CPU makes a bus request, the on-board and 
dual-port buses simultaneously determine if they can 
fulfill it. If the on-board bus can acknowledge the 
request, it does so, and the DP bus control is not 
required to determine if the DP bus can acknowledge 
the request. If the DP bus, not the on-board, can 
acknowledge the request, it does so, and the controller 
then lets the CPU use the bus. Thereafter, the RAM 
controller completes the operation and generates an 
acknowledge signal. 

If neither the on-board nor DP bus can fill the bill, 
the Multibus is solicited by the CPU. Since a bus can 
only communicate with an adjacent bus, the on-board 
bus must request the DP bus to communicate with 
the Multibus via the DP controller. The on-board bus 
will retake control of the DP bus only after the request 
to use the Multibus is granted. This prevents lockout 
problems with the DP bus, where the CPU requests 
the Multibus when it is controlled by another bus 
master accessing the DP RAM. 

How the 80/30 performs is directly related to how 
many buses it must use to complete a requested 
operation. The on-board bus always operates at max- 
imum processor speed. The DP bus operates at max- 
imum only if it hasn't been busy and a memory refresh 
cycle was not in process. The processor speed when 
the Multibus is used depends on bus overhead involved 
and the type of module requested. 

The 80/30 boasts more than a three-bus architec- 
ture. For one thing, its I/O is designed to interface 
to a wide variety of external devices, including 
switches, motor drives, bistable sensors, displays. 
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The iSBC 80/30 uses the latest LSI components to 
obtain the highest performance of any Intel single- 
board computer. Built on a 6.75 X 12-in. board, it 
contains the following features: 

■ 8085A central processor operating at 2.76 MHz. 

■ 16-kbytes of dual-port RAM using Intel's new 16- 
kbyte dynamic RAMs and 8202 dynamic RAM con- 
troller. 

■ Sockets for 2, 4 or 8-kbytes of ROM using Intel's 
2758, 2708, 2716, or 2332 EPROMs or ROM re- 
placements. 

■ A socket for Intel's 8041A/8741A universal pe- 
ripheral interface (UPI) having 18 software-con- 
figurable I/O lines with sockets for drivers/termi- 
nators. 

■ A programmable serial-communication channel 
with RS-232 interface and programmable baud rate. 

■ Multibus control logic which allows up to 16 
masters to share the system bus. 

■ 12 vectored priority interrupts. 

■ Two programmable 16-bit BCD or binary internal 
timers. 



keyboards, printers, teletypewriters, communicator 
modems, cassettes and other computers. This ver- 
satility is provided with LSI programmable devices 
such as Intel's 8255 programmable parallel I/O device, 
8251A programmable communication channel, 8253 
interval timer, 8259 interrupt controller, and 
8041A/8741A universal peripheral interface (UPI). 

The slave processor 

The ability to interface this wide variety of external 
devices is facilitated by the 8041A/8741A UPI (Fig. 
4), which can be added to the 80/30. The UPI is a 
complete single-chip microcomputer which acts as a 
peripheral to the 8085A. It is completely user-pro- 
grammable with 1-kbyte of ROM (8041A) or EPROM 
(8741A) memory for data storage. The UPI allows you 
to fully specify your control algorithm in the peripher- 
al chip without relying on the 8085A. Devices such 
as printer controllers and keyboard scanners can be 
completely self-contained, relying on the 8085A only 
for data transfers. 

The UPI is a powerful 8-bit CPU with a 2.6-ms cycle 
time and an instruction set optimized for bit manipu- 
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4. The 8041A/8741A singie-chip microcomputer (UPI-41) 
has its own on-chip ROM and RAM and can be pro- 
grammed to perform various peripheral control functions. 
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5. The UPl's two data registers are organized so that the 
8085A CPU can write in just one register and read from 
the other. As a result, the two registers appear as one 
register to the main 8085A CPU. 



lation and I/O operations. It contains an 8-bit 
counter/timer, buffers to communicate with the 
8085A, and two 8-bit programmable I/O ports, which 
can be customized by software or by plugging in 
suitable line drivers or terminators into sockets. The 
UPI also has two input bits that it can test directly. 
An RS-232 driver and receiver on the 80/30 permit 
the UPI to be programmed as a simple serial-com- 
munication channel. 

Interfacing to the on-board bus 

The UPI interfaces asynchronously with the on- 
board bus using two data and two status registers. 
The UPFs two internal data registers appear to the 



8085A as only one register, since one data register can 
be written into only by the UPI and read only by the 
8085A, and the other can be written into only by the 
8085A and read by the UPI (Fig. 5). This is done to 
prevent the two CPUs from simultaneously writing 
into a data register. 

The UPI can communicate with the 8085A by 
loading a data register and then returning to its 
previous control task. The 8085A can periodically poll 
the UPI status port for the valid-read ( VR) flag, which 
is set in hardware when the UPI writes to its data 
port,'Or the UPI can generate an interrupt to the 8085A 
via an I/O bit that can be programmed to be the VR 
flag. 

Once the 8085A determines the VR flag is true, it 
can transfer the data to its own memory without 
disturbing the UPI. The VR flag is automatically 
cleared after the data are transferred. Similarly, when 
the 8085A transfers data to the UPI, a valid output 
(VO) flag is set and an interrupt to the UPI is 
generated (if enabled) automatically. Once the UPI 
transfers the data, the VO flag is cleared. The VO flag 
can also be programmed to a port bit for generating 
interrupts to the 8085A to indicate that the transfer 
is complete. 

An extensive interrupt system 

The 80/30 provides 12 vectored priority interrupts, 
four of which are handled directly by the 8085A's 
interrupt-processing capability and routed to fixed, 
unique memory locations. The remaining eight levels 
are handled via the 8259A programmable interrupt 
controller (PIC), which generates a unique memory 
address for each level. These addresses are equally 
spaced at intervals of four or eight (software-selec- 
table) bytes. This 32 or 64-byte block may be located 
to begin at any 32 or 64-byte boundary in the 65,536- 
byte memory space. A single 8085A jump instruction 
at each of these addresses then provides the linkage 
to locate each interrupt-service routine independently 
anywhere in memory. The PIC provides a selection 
of four priority algorithms so that the manner in 
which real-time requests are processed may be con- 
figured to meet the requirements of the system under 
design. 

The 80/30 also has two 8253-based programmable 
16-bit BCD and binary timers/event counters, which 
can be used for a variety of functions. Both timers 
may be set to act as a rate generator (divide-by-N 
counter), a square-wave generator, a programmable 
retriggerable one-shot, or one of the timers can be 
jumper-selected as an event counter. In addition, an 
interrupt can be generated when a time interval has 
expired or when a specified number of events has 
occurred. 

To see how useful the 80/30 can be, consider a 
supervisory control/monitoring system (Fig. 6) using 
an Intel iSBC 80/30 single-board computer, iSBC 201 
diskette controller, and iSBC 732 analog input/output 
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board. Here local commands and process-status sig- 
nals are given and displayed on a CRT, which is 
interfaced via the iSBC 80/30 resident UPI and 
RS232C components. Process variables are converted 
from analog to digital using the analog I/O board. 
Control variables are passed over the Multibus from 
the 80/30 to the 732, where they are converted from 
digital to analog. 

System data are logged on two diskettes, which are 
controlled by the 201. The controller board's on-board 
DMA interface accesses the 80/30's dual-port memory 
and stores the data on one of the floppy discs. 

At the end of the day, a remote host processor, 
interfaced to the 80/30 via a modem (through the 
80/30's 8251A and RC232C circuits) can request all 
or part of the diskette-resident data. Here, the 80/30 
uses its on-board dual-port memory as a data buffer 
for transfers to the host. 

Intel's RMX/80 real time executive, disc-file system 
and analog drivers provide the majority of the 
system's software.Ho 

Note: Multibus and iSBC are registered trademarks 
of Intel Corp. 



6. In this application example, the 80/30 forms the heart 
of a remote data-acquisition system. By taking advantage 
of the one-board microcomputer's dual-port memory and 
universal peripheral interface, the system achieves a 
combination of attractive cost and efficiency. 
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Dual-port RAM hikes throughput 
in input/output controiier board 

On-board random-access memory, accessible from system bus, 

makes input/output controller subsysterri look like 

just another memory board to the host microprocessor 



by Craig Kinnie and Michael Maerz, imeicorp.. santaciara. caiit 



D Input/output controllers based on microprocessors 
step up throughput in microcomputer systems by reliev- 
ing the host processor of tedious, time-consuniing control 
tasks— and a new design concept that increases the 
processing capability of this subsystem promises to hike 
throughput even more. It will cut the host intervention 
needed to transfer data and to run the controller. 

In this configuration, all communications between the 
host processor and the controller are handled through a 
section of dual-port memory that resides in the controller 
subsystem. This setup allows more efficient transfer of 
large blocks of data from the i/o device to the system 
without contention over access to the system bus. It also 
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simplifies interprocessor communications because the 
subsystem controller appears to the host processor sim- 
ply as an additional ram board. 

Although this concept allows the subsystem to remain 
dedicated to its i/o control function and to assume a 
subservient role to the host processor, it has more 
processing power than previous generations of such 
controllers. Hence it lias been dubbed the ii>telligent- 
slave concept by Intel, which applies it incite iSBC 544 
intelligent communications controller. / 

The new subsystem architecture is divided into three 
major sections: dedicated I/O, dedicated computer, and 
dual-port memory (Fig. 1). The dedicated input/output, 



1. Heart of memory. New controller archi- 
tecture includes the dedicated input/output 
circuitry and dedicated processor of an intel- 
ligent peripheral controller, but its heart is 
the dual-port random-access memory. 
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2. Performance advantages. In adding a real-time task to an existing real-time system, the load on the system bus is significantly reduced 
over the traditional multitasking approach (a) or the intelligent controller approach (b) by the intelligent-slave controller approach (c). 
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3. The 544. Based on the 8085A microprocessor with 4 kilobytes of PROM and 16 kilobytes of RAM, the subsystem Is designed i 
communications controller with four synchronous /asynchronous buffered serial I/O channels, and a 10-bit parallel I/O interface. 
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Dual-port RAM atso shows up in new single-board computer 



The concept of a dual-port read-write memory used in tlie 
JSBC-544 communications board Is also employed in 
another new Intel product: its latest single-board comput- 
er, the iSBC-80/30. A dual port makes the 80/30's 
random-access memory directly accessible by the on- 
board 8085A central processing unit via internal busing 
without tying up the external system bus, the Multibus. At 
the same time, It also makes the RAM directly accessible 
by any other boards, like direct-memory-access control- 
lers or other one-board computers that may be tied to the 
Multibus. 

Moreover, the 80/30 adds its dual-port bus to the 
earlier ISBC computers' pair of buses: an internal bus, 
which hooks the CPU to peripheral chips and read-only- 
memory program storage and the system bus, over which 
the CPU and other boards communicated with RAM. Eight 
bits wide, the new bus is connected to a pair of buffer 
registers that coordinate, thus making the RAM accessible 
either by the internal bus or the system bus. 

The objective is throughput: the CPU has priority in 
access to the on-board RAM. But since the access is not 
over the Multibus system bus, which might be tied up, 
there is no waiting. From the viewpoint of other system 
boards, the system bus is accessible a greater percentage 
of the time. 



With the incorporation of 16 kilobytes of memory on the 
80/30, Intel had little choice but to move to the dual-port, 
triple-bus architecture. The reason is that few system 
designs require more than 16 kilobytes, so In many appli- 
cations all boards will be demanding access to the 
80/30's memory over the Multibus. The CPU had better 
have priority to Its RAM, through its own private line, Jest 
the queue for the system bus bog down throughput. 

The 80/30 also packs lots of extras, in addition to the 
total 16,384 bytes of read/write memory built with 2116 
16-K dynamic RAMs. A pair of ROM sockets provide 
4,096 bytes of program storage if fitted with 16-K erasable 
programmable read-only memories like the 2716. When 
pin-compatible 32-K erasable PROMs are available, 
program storage can be extended to 8 kilobytes. 

Also on board is a socket for Intel's universal peripheral 
Interface chip, the 8041 (or 8741 erasable-PROM 
version), which can function as a slave processor to drive 
peripheral devices. An 8251 A universal synchro- 
nous/asynchronous receiver/transmitter Is included for 
serial communications, and the 80/30 also boasts three 
16-bit programmable timers. The 24 programmable 
input /output lines are brought out to sockets that accept 
quad line-drivers or -terminators for interfacing. 

RayCapece 



consisting of the necessary peripheral chips, timers, 
buffers, and interface integrated circuits, tailors the 
controller to the application's i/o requirements. 

The dedicated computer consists of a general-purpose 
microprocessor, electrically programmable read-only 
memory, dedicated ram, timers, interrupt logic, and the 
decode and chip-select logic. The size and speed of the 
central-processing unit can be tailored to match the 
requirements of the dedicated i/o section. 

The dual-port memory is the heart of the architecture 
and sets it apart from traditional approaches to intelli- 
gent controllers and multiprocessing. Passing all 
commands and data between the system and the control- 
ler's processor through this memory offers a number of 
significant advantages. 

First, the dedicated computer's performance can be 
optimized for its applications. Its software always oper- 
ates at full speed, since all required memory and I/O 
resources are immediately accessible on the board, with- 
out indeterminate delays caused by other system activity 
on the bus. This accessibility is especially important in 
real-time systems, since it allows the controller's 
performance to remain constant even though system bus 
activity may change. 

Secondly, the architecture presents a consistent and 
convenient interface between the host CPU and all the 
controllers in the system, regardless of function. Because 
the controllers' dual-port ram looks to the host CPU like 
just another location in system memory, the hardware 
and software problems associated with connecting multi- 
ple processors together are reduced to interfacing a 
number of identical intelligent memory locations. 

Also, the architecture offers a degree of protection for 
the data in memory. The subsystem computer and soft- 



ware can only alter that portion of system memory that 
resides in its own dual-port memory section. In contrast, 
traditional intelligent controllers have access to the 
entire system RAM and, should a malfunction occur, can 
destroy all of that memory. 

System performance advantages 

Because all processing assigned to the new controller's 
CPU takes place off the system bus, its architecture offers 
important performance advantages to the system. These 
advantages come from the appearance of the processed 
data blocks in system memory without consuming any 
system resources or bus time 

The advantages of this approach are best demon- 
strated by comparing it to alternative means of adding a 
real-time task to an existing real-time system. In this 
case, the new task requires additional CPU, memory, and 
I/O resources. 

The traditional multiprocessor approach of Fig. 2a 
expands CPU resources in one of two ways: software 
utilization of reserve capacity in the existing processor, 
or adding another processor. In either case, memory and 
I/O increments generally will be required. 

The primary disadvantages of this approach are the 
increased complexity of the system software and the 
increased load on the system bus. Both will slow the 
existing real-time system unless it has been designed 
with adequate reserve. The system bus must also provide 
sufficient capacity for the incremental memory-execu- 
tion and data-transfer operations. This additional bus 
load will also require that the primary real-time task can 
tolerate CPU delays due to bus contention. 

The intelligent-controller approach of Fig. 2b has 
gained widespread use since the advent of the micropro- 
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4. Memory mapping. The variable system memory addresses are 
always mapped Into the on-board address of 8000HEX, providing 
software independence for the subsystem and the host. 

cesser. This approach combines the CPU and i/o incre- 
ments onto a single module that usually includes direct- 
memory-access transfer logic. In some cases the execu- 
tion memory for the CPU is included. 

This approach lessens the bus-loading problem since 
the I/O data transfers and some memory-execution cycles 
take place off the system bus. However, both CPUs' 
programs will have to tolerate delays caused by 
increased bus contention. Increased software sophistica- 
tion is the primary disadvantage of this approach, much 
as with the multiprocessing approach of Fig. 2a. 

The intelligent-slave approach of Fig. 2c can be 
viewed as a logical extension to the intelligent-controller 
approach. Combining the CPU, i/o, and memory incre- 
ments creates a single module that has a minimal impact 
on the existing system software and bus loading. What's 
more, the subsystem can operate at full capacity without 
regard to other system activity. It can be programmed 
outside the primary system and then added with minimal 
impact on the system software or performance. 

A limitation of the approach is the inability of the 
subsystem to transfer data into portions of the system 
memory space that reside off its board. This problem is 
minimized by the ability of the controller's ram to serve 
as a substantial portion of the entire memory space 
addressable by the system. In this light, the on-board 
processor can be viewed as having a DMA capability 
limited to a portion of the system's address space. 

In a system with more than one of the new controllers, 
the system CPU handles any data that must be trans- 
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ferred from one to another. Applications involving the 
transfer of large blocks of data would be best served by a 
central block-transfer device elsewhere on the bus. 

The advantages offered by the new approach in this 
example of adding onto an existing system are just as 
applicable to a ground-up design. This modular 
approach to configuring real-time multiprocessing 
systems simplifies hardware and software design, as well 
as system integration. 

While the primary design objective of the new archi- 
tecture is operation in a multiprocessing system, it can 
provide significant utility as stand-alone processors. 
Thus these controllers incorporate a second mode of 
operation called the limited bus-master mode. 

In this mode of operation the new controller can be 
used like a single-board computer as long as it is the 
system's only master of the bus. It can be connected to 
standard memory or i/o expansion boards to enhance its 
capability. It can even be used to drive other such 
controllers as long as they are used in the subsystem 
mode. This dual operational mode will allow the new 
controllers to serve a broad range of applications. 

Communications first 

Communications applications present complex pro- 
cessing requirements and an inherent real-time nature, 
so it is logical that a communications processor be the 
first of these new controllers to be marketed. The iSBC 
544 intelligent communications controller can serve as a 
flexible front end to an iSBC system or as a cost- 
effective stand-alone processor configured as a terminal 
cluster or line concentrator. Its design (Fig. 3) incorpo- 
rates an 8085 A CPU, 16 kilobytes of dual-ported dynamic 
RAM, 4 kilobytes of prom, programmable interrupt 
control, three interval timers, four programmable baud- 
rate generators, four synchronous/asynchronous buf- 
fered serial i/o channels, and a 10-bit parallel interface 
compatible with a Bell 801 automatic calling unit. 

The dual-port memory block basically consists of the 
16-kilobyte bank of random-access memory, which is 
accessible from either the system bus or the on-board 
processor through the dual-port controller. This memory 
block provides the primary means of communication 
between the system and the on-board 808 5 A. The port to 
the memory, which looks to the system bus like any other 
RAM card belonging to the system, features full 20-bit 
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addressing and a typical access time of 600 nanoseconds. 

The interface's address-decode logic allows switching 
of the base address of the iSBC 544 to any 4-kilobyte 
boundary in the host system's address space. In addition, 
the user may reserve 8, 12, or 16 kilobits of the 544's 
memory for use by the on-board processor only. This 
reserved memory is not accessible from the system bus 
and does not occupy any system address space. The only 
restriction is that all of the unreserved memory reside in 
the same 64-K address page of the system memory. 

This memory division can be a significant advantage 
in large 8-bit microcomputer systems. Only that portion 
of the controllers' memory needed to pass data between 
CPUS must be made accessible to the system. The 
remaining buffer and execution memory does not 
consume any system address space. 

The net result is an increase in the system's overall 
memory capacity. For example, a microcomputer system 
that would usually be limited to 64 kilobytes of memory 
has a total memory capacity of over 190 kilobytes when 
driving seven 544s. 

Address maps and interrupts 

To the on-board processor, the base address of its 
memory is fixed at 8000hex. Furthermore, all on-board 
addresses are fixed, so that multiple 544s operating on 
the same system bus can be running identical programs 
regardless of their base address on that bus. This capa- 
bility necessitated the address-mapping logic to trans- 
form addresses from the system bus into the equivalent 
in the on-board address space starting at location 
8000HEX (Fig. 4). 

The address-mapping logic also implements the flag- 
interrupt feature. It provides an interrupt to the on- 
board processor whenever a byte is written into the 544's 
base address from the system bus, and a read from the 
on-board processor to the base address clears the inter- 
rupt. Since each 544 in a system has a diff*erent base 
address in that system's ram, it also has a unique 
interrupt. This flag-interrupt capability is a key element 
in establishing a protocol for communications between 
the host CPU and the subsystems' processors. 

The dual-port control logic is responsible for resolving 
contention over access to the memory and is designed to 
optimize the performance of the subsystem CPU. Unless 
the system bus has initiated a memory cycle befofe the 
on-board processor requests memory, that CPU runs at 
full speed. The maximum delay that can be encountered 
is one memory cycle. The arbitration logic actually 
reserves the memory for the on-board processor before it 
generates the necessary commands. This advance reserv- 
ing guarantees that the on-board CPU will suff'er mini- 
mum intervention from system bus accesses. 

When the iSBC 544 is used in the stand-alone limited 
bus-master mode, the dual-port logic is disabled and the 
bus interface buff'ers are turned around to drive onto the 
bus. This reversal allows the on-board central-processing 
unit access to the memory of other subsystems or i/o 
expansion boards on the system bus. 

The dedicated computer is built with an 808 5 A cpu 
operating at 2.76 megahertz, between 2 and 4 kilobytes 
of PROM and ROMs or 8 kilobytes of ROM using 2332 
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5. Communications applications. Two typical applications of tlie 
new iSBC 544 would be as a front-end communications processor to 
a microcomputer system and as a remote concentrator to a series of 
point-to-point or multidrop connected terminals. 

mask-programmable parts, 256 bytes of static ram, two 
16-bit and one 14-bit interval timers, and a 8259 
programmable interrupt controller for individual receive 
or transmit interrupt inputs for each serial port. 

Special command-decode logic was added to the CPU 
to allow it to operate at maximum speed independent of 
other system activity. There are 21 sources of interrupt 
on the 544, including the separate transmit and receive 
interrupts for each port and separate timer interrupts. In 
addition to receiving an interrupt from the system, the 
544 can also send an interrupt to the system bus via the 
808 5 A's serial-output data line. 

Since this controller is intended for communications 
applications, latched interrupts are provided directly to 
the CPU for loss of carrier and ring indicator for all four 
1/0 ports. The ring-indicator and carrier-detect lines car 
also be monitored through the parallel port. 

Dedicated I/O 

The dedicated-i/o section of the 544 provides a high 
degree of flexibility and programmability. This results 
primarily from the inclusion of four 8251 A universal 
synchronous/asynchronous receiver/transmitters. These 
devices are programmable for synchronous or asynchro- 
nous mode, character size, parity bits, stop bits, and 
baud rates. Data, clocks, and control lines are buff'ered 
with RS-232-C-compatible drivers and receivers to four 
26-pin card-edge connectors. Each port is configured as 
a data-terminal interface, but may be converted to a 
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6. From slave to master. In its stand-alone mode, the 544 can operate as a bus master and be configured as an Intelligent terminal controller 
connecting dumb terminals to a data link (a) or as a peripheral controller connecting RS-232-C-compatible units to the terminal (b). 



data-set interface by changing a single jumper-plug 
assembly. The ports support most RS-232-C signals 
(those that are listed in the table). 

A programmable baud-rate generator is also provided 
for each port. The range of baud rates available is 75 to 
56 kilobits per second. The generators are implemented 
with 8253 programmable interval timers, vi'hich receive a 
jumper-selectable input frequency of 1.84 or 1.23 MHz. 
In addition, one of the CPu's interval timers can be 
converted to baud-rate operation and jumpered to any 
port to provide it with split-speed operation. 

The 544 also provides a parallel port with four 
RS-232-C buffered input lines and six RS-232-C 
buffered output lines. This port is configured to interface 
to most automatic calling units but may be used as a 
general-purpose i/o port. It is implemented with an 8155 
programmable peripheral interface that also provides the 
256 bytes of static ram and the 14-bit timer. 

Applications 

A likely common use of the 544 as a subsystem is as a 
front-end processor or terminal multiplexer (Fig. 5) in 
an iSBC system. The 544 performs all communications- 
related functions such as format control, code conver- 
sion, data-link control, error checking, data compression, 
and protocol management. It can handle multiple proto- 
cols, line speeds, and data formats. 

All the system processor sees are the processed data 



blocks that appear in system memory. An automatic 
dialer could be added to provide a dial-up connection to 
a host processor or network. 

Also shown in Fig. 5 is another 544 used in its limited 
bus-master mode as a remote concentrator and terminal 
controller. The line and memory capacity of the remote 
concentrator can be increased by the addition of stan- 
dard iSBC memory and i/o expansion boards. 

The intelligent-terminal controller shown in Fig. 6a is 
a prime example of a 544 used in the stand-alone mode. 
It can connect one or more dumb terminals to a data link 
and provide the necessary buffering, code conversion, 
and data-link control. It could also connect a terminal 
that happens to communicate in a different protocol to a 
new network or to more than one network. 

The iSBC 544's multiple serial lines do not have to be 
used for communications. They can also be used to 
connect RS-232-C-compatible peripherals to the termi- 
nal (Fig. 6b). In this configuration, the 544 can provide 
message editing and formatting, bulk storage, and hard- 
copy output. 

As this last application suggests, the 544 is the 
vanguard of a family of intelligent I/O controllers that 
will add tremendous increases in throughput and versa- 
tility to the iSBC line of single-board computers. The 
basic architecture will simplify the task of developing 
multiprocessing hardware and software solutions that 
will overcome throughput limitations. D 
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Technical articles 



16-bit single-board computer 
maintains 8-bit famiiy ties 

Three-bus 8086-based board addresses a megabyte, 
communicates over expanded system bus 

by Robert Garrow, Jim Johnson, and Les Soltesz, inteicorp., santaciara. cant 



D For the first time ever, 8- and 16-bit single-board 
computers can brainstorm over the same system bus. 
The iSBC 86/12 16-bit SBC has been designed to work 
intimately with its predecessors, the iSBC 80 family of 
8-bit boards. What's in it for the user? Design flexibili- 
ty— 8-bit designs can be enhanced to 16 bits, developed 
software can be transported and, beyond that, 8- and 
16-bit devices can be mixed in multiprocessing configu- 
rations. Several features make these options possible: a 
16-bit CPU and instruction set designed for 8-bit compat- 
ibility; greatly expanded memory resources; and an 
extension of the Multibus specifications. 

At the heart of the iSBC 86/12 is a 16-bit, high- 
performance metal-oxide-semiconductor 8086 central 
processing unit that operates at 5 megahertz. Because 
the 8086 instruction set is a superset to that of both the 
8080A and 8085A 8-bit processors, the CPU can execute 
the full set of 8080A/8085A-type 8-bit instructions plus 



a new set of 16-bit instructions. Thus, programs gener- 
ated for 8-bit-CPU systems can easily be upgraded to run 
on the iSBC 86/12 using the software tools available 
with the Intellec microcomputer development system. 
Programs written in Intel's high-level programming 
language, pl/m, can be executed on both iSBC 80 and 
iSBC 86 products, preserving the software investment in 
8-bit systems as a user moves into 16-bit applications. 

Other features of the 8086 CPU are signed 8- and 
16-bit arithmetic (including multiply and divide), effi- 
cient interruptible byte-string operations, and improved 
bit manipulation. Furthermore, the 8086 provides mech- 
anisms for reentrant code, position-independent code, 
and dynamically relocatable programs. 

This enhanced processing power is supported by the 
largest memory ever offered on a CPU board (Fig. 1). 
Memory address space has been extended over the iSBC 
80 series to one million bytes. Up to 16 kilobytes of 
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1. What a board. The iSBC 86/12 has 32 kilobytes of RAM and room for 16 kilobytes of ROM. The 5-MHz 8086 CPU executes 
8080A/8085A-type as well as 16-bit instructions, including multiply and divide. Address space has been increased to a megabyte. 
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2. LSI + SBC =86/12. A number of programmable LSI devices take credit for the power and flexibility of the iSBC 86/12. Note their 
interconnection to the three-bus hierarchy. When the 8086 requests a resource, the system bus is used only as a last resort. 



re&d-only memory can be installed on the iSBC 86/12 
itself. Furthermore, an additional 32 kilobytes of 
dynamic random-access memory with on-board refresh 
may be accessed independently by the CPU or by the 
system bus (Multibus). 

Like the iSBC 80/30, the 86/12's ram has dual ports 
to extend its use off board for access by other Multibus 
masters, including single-board computers, direct-memo- 
ry-access devices, and peripheral controllers [Electronics, 
Aug. 17, p. 109]. All memory operations on the board 
occur independently of the Multibus, freeing it for exter- 
nal parallel operations. For applications that require 
data integrity at all times, a separate bus supplies power 
to the RAM and support logic via the edge connector. An 
auxiliary power source energizes the ram in the event of 
power failure. 

Multibus— the new look 

To exploit the greater performance of the 8086 CPU 
and simultaneously make the iSBC 86/12 fully compati- 
ble with the iSBC 80 family of SBCs and expansion 
products, the Multibus specification has been extended 
to support 20 bits of address and 16 bits of data. The 
control lines, too, have been expanded to direct 8- and 
16-bit data transfer over the system bus. These improve- 
ments enable the iSBC 86/12 to address directly a full 
one megabyte of system memory, access data in 8- or 
16-bit word lengths, and recognize and acknowledge a 
variety of interrupts. 

Address space has been enlarged to 1 megabyte by 
adding four address lines, A10-A13. Next, 8- and 16-bit 



data operations have been defined to permit both types 
in the same system. This is done by reorganizing the 
memory modules, adding one new signal and redefining 
another. The memory is divided into two 8-bit data 
banks, which form a single 16-bit word. The banks are 
organized such that all even-byte-addressed data is in 
one bank (D0-D7) and all odd-byte-addressed data is in 
the other bank (Ds-Df). A new bus-address signal has 
been defined to control the odd-byte bank called byte 
high enable (bhen) during 16-bit operations. When 
active, bhen enables the high byte of the data word from 
the addressed boards on the Ds-Df Multibus data lines. 
Ao controls the even byte bank and, when inactive, 
enables the low byte of the data word on the D0-D7 
Multibus data lines. All word operations must occur on 
an even-byte-address boundary with bhen active for 
maximum efficiency. (Ao is inactive for all even 
addresses— see the table.) Word operations on odd-byte 
boundaries will be converted to 2-byte operations by the 
8086, one for low-byte, one for high-byte. Byte opera- 
tions can occur in one of two ways. The even bank is 
accessed when bhen and Ao are both low. This puts the 
data on D0-D7. To access the odd bank (normally placed 
on Dg-Dp during a word operation), a new data path has 
been defined. The active state of Ao and the inactive 
state of bhen are used to enable a swap-byte buffer, 
which places the odd data bank on D0-D7. This permits 
an 8-bit master access to both bytes of the data word 
while controlling only Ao. Ao therefore specifies a unique 
byte and is not part of the word address, since all word 
operations are on even-byte boundaries. 
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Flexibility: LSI chips are the key 



The iSBC 86/12 owes much of its flexibility to program- 
mable large-scale integrated devices. An 8255A peripher- 
al interface chip provides 24 programmable I/O lines that 
may be tailored to the customer's needs by simply 
programming the device for input, output, or bidirectional 
modes with or without handshaking abilities. In conjunc- 
tion with the 8255A's configuration the user may then 
select appropriate line drivers and terminators for the I/O 
lines that can be inserted into sockets on the iSBC 86/12 
board. 

An 8251 A universal synchronous/asynchronous receiv- 
er/transmitter is included to provide an RS-232-C inter- 
face for serial communication with other computers, RS- 
232-C-type peripherals (cassette tape, modems, etc.) or 
cathode-ray-tube terminals. The 8251 A enables the user 
to customize the communication link. Synchronous/asyn- 



chronous mode, data format, control character format, 
parity and baud rates from 75 to 38.4 kilobauds are all 
under program control. 

For system timing functions an 8253 programmable 
Interval timer provides two programmable timers, each of 
which may be used as a square-wave generator, retrigger- 
able one-shot multivibrator or as an event counter. 

The interrupt structure of the ISBC 86/12 encompasses 
nine levels with vectored priority. Eight of these levels are 
handled by an 8259A programmable interrupt controller 
chip, which may be configured for different priority 
processing modes in accordance with the application. 
One nonmaskable interrupt is available to immediately 
alert the CPU to catastrophes like a power failure, in which 
case the CPU can branch to an appropriate routine in 
memory to effect an orderly system shut-down. 
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3. RAM, please. The 8086's view of on-board memory is fixed from zero to 07FFFH. When an outside master accesses this space, the DP 
controller performs the translation. Here, locations 06000H to 07FFFH are available to another master by addressing CAOOOH to CBFFFH. 



Since all 8-bit accesses via Multibus are done on the 
lower byte of the data word, the iSBC 86/12 can access 
8-bit memory or I/O devices from the system bus. This 
makes the iSBC 86/12 compatible with all iSBC 80 
Multibus modules. 

More interrupts, too 

The iSBC 86/12 expands the previous Multibus defi- 
nition of interrupts by creating two distinct types: non- 
bus- vectored (nbvi) and bus-vectored (bvi) interrupts. 
Each Multibus interrupt line can be individually defined 



through software to be a bvi or nvbi. Using BVis, the 
interrupt capability of a Multibus system can be 
increased to 64 bus- vectored-priority interrupts. 

Using NBVis, a slave module activates an interrupt line 
and the interrupted bus master generates its own restart 
address to service that interrupt. The Multibus address 
or data lines are not used. A Bvi uses the Multibus 
address and data lines to communicate with the inter- 
rupting slave. When the slave module generates an inter- 
rupt, the bus master requires that module to generate the 
restart address. One additional command signal is 
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4. Open loop. Shown above is a simple alarm and monitoring system. The iSBC 711 analog-input board samples 16 differential inputs and the 
8-bit iSBC 80/20 compares the inputs to the high and low limits. An alarm condition illuminates an LED and gets logged on a teletypewriter. 
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5. Closed loop. Suppose the system in Fig. 4 needs to be upgraded to handle a closed-loop system. For this application an iSBC 86/12 
replaces the 80/20-04 to cope with the higher processing. The output control variables are handled by an iSBC 724 analog-output board. 
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6. Multi/ master. To enhance the control system in Fig. 5, add a dedicated CPU to control valves, vents, and dampers that, in turn, affect 
pressure and flow parameters in the system. This has been done by adding an iSBC 80/05 in a Multibus/multimaster arrangement. 



defined — interrupt acknowledge (inta) — to request the 
restart address from the slave module. 

The iSBC 86/12 board architecture, like that of the 
8-bit iSBC 80/30, is organized around a three-bus hier- 
archy: an on-board bus, a dual-port bus and a system bus 
(Multibus). All three buses have been expanded over 
their 80/30 counterparts to incorporate 20 address lines 
and 16 data lines. 

The iSBC 86/12 architecture 

The on-board bus links the 8086, all the I/O peripher- 
als, and the read-only memory. Next in the hierarchy is 
the dual-port bus, which connects to the dp controller, 32 
kilobytes of dynamic ram, and the dynamic ram 
controller. Finally, the system bus permits expansion of 
system resources through Multibus modules (Fig. 2). 

The bus protocol of the iSBC 86/12 dictates that each 



of the three buses communicate with an adjacent bus or 
operate independently. When the CPU makes a request 
for a resource, the on-board and dual-port buses simulta- 
neously determine if their hardware can fulfill the 
request. If the on-board bus is able to acknowledge the 
request, it does so and the DP bus is not disturbed. (The 
DP bus is not interrupted to determine whether it can 
acknowledge the request.) The 8086 always controls the 
on-board bus, and requested operations can be 
completed without delay. If the dp bus is needed, it is 
requested and the dual-port controller grants the use of 
the bus to the processor. Thereafter, the dynamic-RAM 
controller completes the operation and generates an 
acknowledge. 

If neither the on-board nor the DP bus can satisfy the 
request, the CPU asks for the system bus. The 8086 must 
use the on-board and dual-port buses to communicate 
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7. Four loops. An iSBC 86/12 can be used in conjunction with an ISBC 544 intelligent communications controller to perform a supervisory 
function for four closed-loop systems. The ISBC 544 controls the line protocol and the iSBC 86/ 12 processes the 544's data. 



with the system bus. The 8086 takes control of the D? 
bus when the system bus is granted. This prevents lock- 
out problems with the DP bus— that is, when the proces- 
sor requests the system bus while another bus master has 
control of it and is accessing the dual-port RAM. 

Naturally, the fewer the buses it has to access, the 
faster the iSBC 86/12 completes a transaction. The 
on-board bus always operates at maximum board speed. 
But the DP bus operates at maximum board speed only if 
it was not busy or taken up with a memory refresh cycle. 
When the system bus is brought into play, the processor 
speed depends on the overhead in acquiring it and the 
type of Multibus module being accessed. 

With this three-bus architecture the iSBC 86/12 can 
be operating over its on-board bus at the same time as 
another Multibus master is using the system bus. It does 
so by accessing data from the dp ram at no reduction in 
board speed. The on-board bus permits access only from 
the 8086. Thus all i/o and ROM are private to the 8086. 

The dual-port controller has two independent address 
decoders— one for the 8086 and one for the Multibus. 
The 8086 decoder fixes the 8086's ram addresses from 
hexidecimal 00000 to 07FFF using a fusible-link 
programmable ROM. The Multibus decoder allows the 
user to select any address range for the on-board ram by 
specifying two parameters— a top-of-memory pointer 
and the size of the accessible memory. The TOM pointer 
(as seen by another Multibus master) can be set to any 
8-kilobyte boundary in the 1 -megabyte memory space. 
The amount of memory on the iSBC 86/12 accessible by 
another master can be set to 8, 16, 24, or 32 kilobytes (or 
no access) with an on-board jumper. For example, fixing 
the accessible memory size to 24 kilobytes provides the 
8086 with 8 kilobytes of ram that only it can access. 
This private area can be used for the processor's stack, 
interrupt jump table and other special system paramet- 
ers that are generally protected from other Multibus 
masters. The only addressing restriction is that the 
memory block accessible to the Multibus cannot cross a 
128-kilobyte boundary. 

Suppose a Multibus master wants to load a program 



into the iSBC 86/1 2's dual-port ram for execution. 
Since the 8086's view of the dp-ram address space is 
fixed, the Multibus address must be translated into the 
on-board 8086 memory space. The dp controller 
performs this translation by mapping the TOM pointer 
(as seen by other Multibus masters) to 8086-address 
07FFFH, the top of the 8086's on-boaird ram. Point- 
er- 1 is mapped to the top of 8086 on-board ram- 1, 
and so on. 

In the example shown in Fig. 3, the Multibus address 
selection is divided into three parts— two selecting the 
TOM pointer (X and Y) and one selecting the size of the 
accessible memory (Z). The TOM pointer is equal to a 
128-kilobyte segment (X) plus address displacement (Y) 
from that segment. In this example, X is set to COOOOH 
and Y is set to OBFFFH, so the TOM pointer equals 
CBFFFH. Next, the size of the accessible memory (Z) is 
set, in this case to 8 kilobytes. This address translation 
makes the top 8 kilobytes of the 8086's ram locations 
06000H to 07FFFH available to another Multibus 
master when it addresses locations CAOOOH to 
CBFFFH. The 8086 still has 24 kilobytes (OOOOOH to 
05FFFH) of private memory. 

Multiprocessing schemes 

In multiprocessing systems, a master must be able to 
access the system without another master obtaining the 
bus. The iSBC 86/12 incorporates bus-arbitration logic 
to effect these transactions. Since the system bus is only 
requested when a system resource is needed, the iSBC 
86/12 can perform true parallel processing with other 
iSBC 80 or 86 masters. 

A typical example is the use of a common memory 
location that contains the status byte (busy/not busy) of 
a floppy-disk controller. When the floppy disk is needed, 
the master must first read the location and, if not busy, 
write the status word without another master obtaining 
the bus (to use the floppy disk). A bus-lock function on 
the iSBC 86, once enabled, allows the iSBC 86 to 
maintain control of the system bus until the lock is 
disabled by program control. This bus-lock function may 
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be activated in one of two ways— by an output bit from 
the resident 8255A peripheral-interface chip or by a 
software prefix on any 8086 instruction. The iSBC 86 
can perform the test and set function by exchanging the 
accumulator with the memory location, preceding the 
instruction by a lock prefix. For example, the status 
word is read into the accumulator and, without another 
intervening bus cycle, a busy status is written. The 
accumulator is then tested: if busy— try again (writing a 
busy does not destroy status as it was already busy); if 
not busy, the floppy disk is now under the master's 
control and the status location is set to busy. 

The iSBC 86/12: a design tool 

For system debugging and full-speed execution, the 
iSBC 86/12 can be linked to the Intellec microcomputer 
development system. Programs generated on the Intellec 
system can be downloaded into the iSBC 86/12 ram via 
cables. Through a virtual-terminal capability, the Intel- 
lec console can directly access an iSBC-resident monitor, 
which provides commands for software debug. Once the 
debugging cycle is completed, the user has the option of 
uploading the software back to the Intellec for storage 
on diskettes. 

The Multibus and form-factor compatibility of the 
8-bit iSBC 80 and 16-bit iSBC 86 single-board comput- 
ers provide a degree of design flexibility previously unob- 
tainable. Initial design problems can be solved with 
low-cost 8-bit hardware. As product requirements 
evolve, 16-bit performance can be added. Eventually, 8- 
and 16-bit multiprocessor solutions can be conveniently 
implemented. 

Consider the application shown in Fig. 4, an alarm 
and monitoring system in a typical process plant. Sixteen 
differential inputs from pressure and flow transducers 
are sampled once every second, then compared to high 
and low limits previously entered through thumbwheel 



switches. The iSBC 71 1 analog-input board takes care of 
sampling the inputs and the 8-bit iSBC 80/20-4 com- 
pares the data to the high and low limits. Whenever 
these limits are exceeded, an alarm led lights up and the 
alarm condition is logged on the system teletypewriter 
along with input identification, high limit, low limit and 
sampled value. 

Closed loops 

Instead of an open-loop system, suppose the design 
must be enhanced to control four output variables— 
thereby making it a closed-loop system. The sampling 
rate must be increased to once every third of a second 
and more processing will be required to run through the 
control algorithm and output the control-loop data. For 
this application, and iSBC 86/12 replaces the 80/20-4 to 
handle the higher processing requirements. An iSBC 724 
analog-output board is also added to provide the four 
output-control variables (see Fig. 5). Carrying this 
example one step further, one may want to dedicate 
another processor to controlling valves, vents, and damp- 
ers that in turn aff'ect pressure and flow parameters in 
the system. This can be done by adding an iSBC 80/05 
in a multimaster arrangement as shown in Fig. 6. 

Finally, an iSBC 86/12 can be used with an iSBC 544 
intelligent communication-controller to supervise four 
closed-loop systems of the type shown in Fig. 6. The 
86/12 of each system interfaces with the supervisory 
system via its serial interfaces, which are connected to 
the iSBC 544's serial ports (see Fig. 7). The iSBC 544 
performs the control functions associated with the line 
protocol. The supervisory iSBC 86/12 can access the 
iSBC 544's dual-port memory and can perform further 
processing of the data received from the four closed-loop 
systems. In this configuration large amounts of memory 
may be required; since the iSBC 86/12 can address up to 
1 megabyte, this presents no problem. D 
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INTRODUCTION 

Software provided by Intel for the iSBC product family includes the RMX/80 Real-Time Multitasking Executive, the 
ISBC 801 RMX/80 FORTRAN Run-Time Package and the ISBC 802 Resident BASIC Interpreter. 

The RMX/80 executive provides users of Intel's ISBC 80 series single board computers with a simple-to-use tool for im- 
plementing microcomputer software. Applications which monitor and control multiple asynchronously occurring 
events are prime candidates for use with the RMX/80 executive. The RMX/80 disk file system, terminal handler, analog 
driver and debugger have all been designed and optimized specifically for single board computer applications. 
RMX/80's modular design, consisting of a series of linkable and relocatable modules, can be configured to optimize 
system software for any specific application. 

The iSBC 801 FORTRAN Run-Time Package and the ISBC 802 Resident BASIC Interpreter provide further enhance- 
ments to the RMX/80 executive. They provide users with a broad choice of programming languages for fast and effi- 
cient implementation of sophisticated system designs. 

Publications reprinted in this section Include an application note, a magazine article and a professional journal paper 
on the RMX/80 executive, and an application note on using FORTRAN with single board computers. 
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INTRODUCTION 

A large number of microcomputer applications 
require the ability to respond to events in real time. 
RMX/80 provides the system software around 
which you can build a real-time multitasking appli- 
cation on Intel SBC 80 Single Board Computers. 
In addition, RMX/80 increases the utilization of 
a Single Board Computer by allowing its resources 
to be shared among several tasks executing concur- 
rently. Synchronization of these multiple real-time 
tasks is handled by RMX/80, freeing you to con- 
centrate your major programming efforts on your 
appUcation. 

This application note begins with an overview of 
RMX/80. Readers who are familiar with the mate- 
rial presented in the RMX/80 User's Guide may 
choose to skip to the next section, a description of 
how to use RMX/80 and the steps involved in 
using it by describing two applications. 

• An interrupt driven minimal terminal handler 
for a CRT or Teletypewriter. 

• A closed-loop analog control subsysteih utiliz- 
ing the Intel SBC 7 1 1 analog-to-digital board. 

Each example has diagrams illustrating the rela- 
tionships between its tasks and exchanges. These 
are useful tools in conceptuaHzing the activities 
taking place in real time. Program listings of the 
appHcations are interspersed with text describing 
the appUcation. 

OVERVIEW 

Real-time systems provide the abiHty to control 
and respond to events occurring asynchronously 
in the physical world. Later in this application 
note, a process control appUcation is described 
that monitors and controls the temperature within 
several chambers. The system controls the process 
by simply turning on and off a heat source. The 
system could also display the temperature on an 
operator's console and permit entry of new set- 
point temperatures and error ranges. 

A single large program could have been used to 
perform the functions in a sequential manner. 
However, this approach may not permit an opera- 
tor to enter control variables at the same time the 
process is being monitored and controUed. In 
contrast, real-time systems do not operate sequen- 
tially. A number of events may all be happening 
at the same time. This concurrence of events is a 
distinguishing characteristic of real-time systems. 



BASIC CONCEPTS 

There are basically three concepts that the user 
must master to effectively use RMX/80. The first 
is the task, an independent program which com- 
petes for resources within the system. The second 
concept is the message. Messages convey data and 
synchronization information between tasks. The 
third concept is the exchange. An exchange enables 
one task to send a message to another. As we will 
see later, the interaction between tasks and ex- 
changes enables the user to implement mutual 
exclusion, communication, and synchronization. 
Mutual exclusion is a technique that controls 
access to a shared resource such as an I/O device 
or a data structure. 

Task 

Under RMX/80, the user codes a separate program, 
known as a task, for each event. An arbitrary num- 
ber of these tasks execute concurrently and are 
subject to synchronization as required by their 
functions. Tasks share resources such as data struc- 
tures and can communicate between themselves. 

Message 

A rnessage is a unit of communication between 
tasks. Together with the exchange mechanism, it 
conveys information between tasks and can syn- 
chronize their operations. 

Exchange 

RMX/80 uses message exchanges for task-to-task 
communication. An exchange is a pair of queues 
represented by a data structure at which messages 
are left by one task to be picked up by another. 
Tasks may send messages to an exchange, and may 
wait for messages at an exchange. A task which 
waits for a message may perform a timed or an 
untimed wait. A timed wait will terminate upon 
the receipt of a message or at the end of the speci- 
fied period of time, even if it has not received a 
message. When a task does an untimed wait for a 
message it is guaranteed that the task will not exe- 
cute again until a message is available for it. A 
representation of the exchange data structure is 
shown in Figure 1 . 

GENERAL CHARACTERISTICS 

In addition to the basic concepts of tasks and ex- 
changes, several other general characteristics of 
RMX/80 are relevant in this overview. 
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Figure 1. Exchange Data Structure 



System Time Unit 

RMX/80 uses a system time unit that is the period 
of time between "ticks" of the system clock. The 
standard RMX/80 system time unit is 50 milH- 
seconds. The system time unit provides timing and 
user task scheduhng. A task may wait at an ex- 
change for a specified number of system time 
units and then continue execution. A task could 
be written to generate messages at specific time 
intervals. Tasks waiting for the messages would 
then be scheduled according to those time intervals. 

Message Producing/Consuming Tasks 

In general, tasks can be classified as message pro- 
ducing or message consuming tasks. The processing 
flow of these types of tasks are usually cyclic in 
nature and can be shown as follows. 
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Figure 2. Message Producing/Consuming Tasks 



A consumer task waits for a message to be posted 
at a particular exchange and takes control of the 
processor only when it has received a message and 
no other tasks of higher priority are ready to exe- 
cute. The consumer task performs some action 
based upon the message and then simply resumes 
waiting until the next message is received. Usually, 
the consumer task acknowledges completion of 
its function by sending a response message to some 
other exchange associated with a task. 



A producer task initiates its function by sending 
a message to another exchange and then surrenders 
control of the processor. The task continues to 
wait until it receives a response to its message. 

Notice that the distinction between these types 
of tasks is relative since most tasks both produce 
and consume messages. However, the producer/ 
consumer concept helps clarify the general struc- 
ture of tasks— tasks are typically programmed 
loops. A producer task performs a function, sends 
a message, waits for a response, then loops back to 
begin again. A consumer task waits for a message, 
performs a function, sends a response, then loops 
back to wait again. 

Interrupts 

Hardware interrupts are treated as messages from 
peripheral devices for which a task can wait, as if 
the interrupt were a message from some other task. 
These messages arrive at particular exchanges, 
called interrupt exchanges, but are otherwise treated 
as described above. The system provides the abil- 
ity to mask particular interrupts so that no mes- 
sages ever arrive at a particular interrupt exchange 
associated with the masked interrupt. In the event 
that the overhead associated with turning an inter- 
rupt into a message is too high, the interrupt can 
be treated by the user directly via a user supplied 
interrupt service routine. 

Task States 

Tasks may exist in a number of states. A task is 
running if it actually has the processor executing 
instructions on its behalf. K ready task is one that 
could be running (any wait for a message or time 
period has been satisfied), but a higher priority 
task is currently running. A task is waiting if it 
cannot be ready or mnning because it is waiting 
at an exchange for a message. A suspended task is 
one that is not permitted to run or compete for 
system resources until it is resumed. The rela- 
tionships between the task states are illustrated in 
Figure 3. 

Priority 

Each task has associated with it a priority that in- 
dicates its importance relative to other tasks in 
the system and relative to the interrupts of peri-: 
pheral devices. RMX/80 schedules a task for exe- 
cution based on the task's priority. Whenever a 
decision must be made on which task should be 



2-6 



run, the highest priority ready task is chosen. Each 
of the eight hardware interrupt levels has a set of 
priorities, one of which must be assigned to the 
task that services the interrupt. When an interrupt 
occurs that task is executed if it is the highest 
priority ready task. At the time a higher priority 
task preempts a lower priority task, RMX/80 
saves all the relevant information about the pre- 
empted task so it can eventually resume execution 
as though it were never interrupted. This process 
is known as a context save. 
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Figure 4. Message Format 
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Figure 3. Task States 



NUCLEUS OPERATIONS 

The RMX/80 nucleus provides several operations 
that you can access with programmed calls. Two 
basic operations are covered in this section (addi- 
tional operations are described in the RMX/80 
User's Guide): 

• RQSEND, send a message to an exchange 

• RQWAIT, wait for a message or time interval 

These two operations provide the capabihty to 
pass messages between tasks in a system running 
under RMX/80. 

Message Format 

The messages used by the send and wait operations 
to convey information between tasks are variable 
in length and contain the information shown in 
Figure 4. 



Fields 

1 . LINK - a 2-byte field used to enter the mes- 
sage on a Hnked list at an exchange. 

2. LENGTH — a 2-byte field containing the total 
length of the message in bytes. The minimum 
message length is 5 bytes (LINK, LENGTH, 
and TYPE). 

3. TYPE — a 1-byte field indicating the type of 
message. 

4. HOME EXCHANGE - an optional 2-byte 
field containing the address of an exchange to 
which this message should be sent when it has 
no further use. This field is very useful in im- 
plementing and managing a pool of messages. 

5. RESPONSE EXCHANGE - an optional 
2-byte field containing the address of an ex- 
change to which a logical response to this 
message should be sent. This field is intended 
to specify the exchange at which a sending 
task is waiting for an acknowledgement 
message if one is needed. 

6. REMAINDER - an optional field of arbi- 
trary length that may contain any data por- 
tion of the message. 

Sending a Message to an Exchange 

The RQSEND operation enables a task to post a 
message at an exchange. When you send a message 
to an exchange, RMX/80 actually posts only the 
address of the message at the exchange, not the 
body of the message. RMX/80 avoids the overhead 
required to move an entire message to an ex- 
change. Thus it is possible to queue a number of 
messages at the same exchange with little overhead 
in either execution time or memory requirements. 
When a task sends a message to an exchange, sev- 
eral functions are performed. 
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• The message is placed on the specified ex- 
change. 

• If there are one or more tasks waiting at the 
exchange, the first task is given the message 
and is made ready. 

• If a higher priority task is thereby made 
ready, the sending task loses control until 
it once again becomes the highest priority 
ready task. 

After a message is sent to an exchange, it must not 
be modified by the sending task. A task which then 
receives the message by waiting at the exchange 
where the message has been posted is free to modi- 
fy the message. The format of the RQSEND opera- 
tion is as follows. 

RQSEND(exchange-address,message-address) 

Message exchanges are defined by the user, and are 
normally addressed symboHcally. For example, 
the exchange used to pass readings from an analog- 
to-digital (A/D) task might be named ATODEX. 
The reading itself could be contained in a message 
with the name RDNG. Thus, a typical call for a 
send in a PL/M program might be as follows: 

CALL RQSEND (.-ATODEX,.RDNG) ; 

The call procedure in assembly language is as 
follows. 

LXI B,ATODEX 

LXI D,RDNG 

CALL RQSEND 

The assembly language rules for passing parameters 
to RMX/80 are the same as for passing parameters 
to a PL/M procedure called from an assembly lan- 
guage module. For 2-byte parameters, the first 
parameter is passed in the B and C registers; the 
second parameter is passed in the D and E registers. 

Waiting for a Message or Time Interval 

The RQWAIT operation causes a task to wait for 
a message to arrive at an exchange. It is also pos- 
sible to delay execution of a task when no message 
is anticipated for the task. The task simply waits 
for the desired time period at a message exchange 
where no message is ever sent. When a task waits 
for a message at an exchange several operations 
are performed. 



• The task is made to wait until a message is 
sent to the specified exchange, or until the 
time Hmit has expired. 

• When a message is available, its address is 
returned to the task. 

• If the time limit expires before a message 
becomes available, a system TIME$OUT mes- 
sage is returned to the task. 

The format of the RQWAIT operation is as follows. 
RQWAIT(exchange-aadress,time-limit) 

The time limit is eritered as some number of sys- 
tem time units (50 milliseconds); a 1 -second wait 
is equal to 20 time units. If zero is specified the 
wait is not tirned, producing an indefinite wait 
until a message is actually sent to the exchange. 
Note that a specified wait of five time units may 
sometimes only produce an actual wait of four 
time units. This can occur if you enter a wait 
immediately before the clock "ticks." In this 
case the count would be decremented immediately 
after entering the wait. Only four full time unit 
periods would lapse before completion of the 
wait. Thus a user who wishes to ensure that at least 
five time units are spent in an asynchronous wait 
must specify six time units in the wait operation. 
A task which waits synchronously to the system 
clock, i.e., performs repetitive timed waits, does 
not have this problem because a new wait is exe- 
cuted following a tick that satisfied the previous 
wait. The following are typical calls for the 
RQWAIT operation. 



PL/M 



PTR = RQWAIT(.ATODEX,20) 



The RQWAIT procedure returns an address value 
which is the address of a message. 

Assembly Language 

LXI B,ATODEX 

LXI D,20 

CALL RQWAIT 

The address of a message is returned in the HL 
register pair. 
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Send — Wait Interaction 

To a large extent, the power of RMX/80 as a pro- 
gramming tool is derived from the interaction 
between send and wait. The interaction includes 
three multi-tasking operations. 

• Communication 

• Synchronization 

• Mutual Exclusion 

In describing these operations, a graphic notation 
for diagramming tasks, exchanges, and their 
interaction (send and wait operations) is useful. 
The notation is described in the next section on 
communication. 

Communication. The most common interaction 
between tasks is that of communication - the 
transmission of data from one task to another 
via an exchange (Figure 5). 




Figure 5. Communication 



Rectangles designate tasks while circles represent 
exchanges. Arrows that are directed from tasks to 
exchanges indicate send operations. Wait opera- 
tions are shown by arrows directed from exchanges 
to tasks. 

Figure 5 shows an example of comrnunication 
between task A and task B. Task A sends a message 
to exchange X and task B waits for a message at 
that exchange. Task A is the message producer 
and task B the message consumer. 

Synchronization. At times there is a requirement 
to send a synchronizing signal from one task to 
another. This signal can take the form of a message 
that contains only header information, that is, 
LINK, LENGTH, and TYPE. 

Let us consider the implementation of a task 
scheduler, used for the purposes of synchronizing 
another task that performs a particular function 
at periodic intervals. The relationship between the 
tasks and exchanges is shown in Figure 6. 




Figure 6. Synchronization 



Task A, the scheduler, performs a timed wait on 
the X exchange. Note that the full wait period 
will always occur because there is no task that 
is sending messages to exchange X. In this manner, 
a specific timed wait by task A precedes the pass- 
ing of a synchronization message from task A to 
task B via exchange Y, and then the return from 
task B to task A via the Z exchange. 

If task B waited on X directly, rather than using 
task A for scheduling, it would be scheduled n sys- 
tem time units from when it waits instead of n 
units from the last time it was awakened. A com- 
parison between the two methods is shown in 
Figure 7. 



TASK B WAITING DIRECTLY ON X TASK A SCHEDULING TASK B 



Figure 7. Scheduling Methods 



Mutual Exclusion. In an environment with multi- 
tasking, resources often must be shared. Examples 
of shared resources include data structures and 
peripherals such as the Intel SBC 3 1 Math Module. 
Mutual exclusion can be used to ensure that only 
one task has access to a shared resource at a time. 
Figure 8 shows how an exchange can be used to 
Umit access to a resource. 
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An alternate solution is to maintain a pool 
of large fixed length messages. The pool can be 
maintained without the Free Space Manager; 
however, memory is wasted because of the unused 
space remaining in the fixed length messages. 

The second appUcation of the Free Space Manager 
relates specifically to effective use of memory. 
In a typical application, the total RAM require- 
ment is computed by adding up the maximum 
RAM requirements for each task in a system as 
shown in Figure 9. 



Figure 8. Mutual Exclusion 



In this example, the X exchange is sent a single 
message at system initiahzation. Then, as tasks re- 
quire the resource, they wait for a message from 
the X exchange. When the message is received, 
the task knows it has sole access to the resource 
because there is only one message associated 
with the exchange. After the task finishes with 
the resource it sends the message back to the X 
exchange. The next task waiting for the resource 
continues, knowing it has exclusive access to the 
resource. 



EXTENSIONS 

RMX/80 has several extensions which provide 
operations commonly used in real-time applica- 
tions. The nucleus of RMX/80 requires less than 
two thousand bytes of memory and includes all 
of the basic operations. The extensions include a 
Free Space Manager, Terminal Handler, Disk File 
System, and a Debugger. 



ROM 




TASKB 


RAM 


Imaxa 


ROM 


RAM 



RAMtoTAL " MAXa + MAXb + MAXc 



Figure 9. RAM Requirements 



The efficiency of memory utihzation is a function 
of the total RAM memory needed during typical 
system operation. Reducing the total amount of 
RAM by sharing it among the tasks often has 
little impact on total performance. However, signi- 
ficant cost advantages may be gained by reducing 
the total amount of memory. The memory require- 
ments can be calculated as the minimum RAM for 
each task plus the pool (shared memory), as shown 
in Figure 10. 



FREE SPACE MANAGER 

The Free Space Manager maintains a pool of free 
RAM and allocates memory from that pool upon 
request from a task. The Free Space Manager also 
reclaims memory and returns it to the pool when 
it is no longer needed. 

The Free Space Manager is especially useful in two 
applications. The first appUcation arises from the 
need for variable length messages. If you have a 
task that produces messages of variable length, 
such as a task sending text for display on a CRT, 
the Free Space Manager can be used to provide 
a message to meet your exact size requirements. 
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Figure 10. RAM Requirements Using a Pool 
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TERMINAL HANDLER 

The Terminal Handler provides real-time asyn- 
chronous I/O between an operator terminal and 
tasks running under the RMX/80 executive. The 
Terminal Handler provides a line-edit capability 
similar to that of ISIS-II and an additional type- 
ahead feature. (ISIS-II is the diskette supervisor 
system used on the Intellec Microcomputer Devel- 
opment System.) Access to the Terminal Handler 
is provided by two exchanges where messages are 
sent to initiate read and write requests. 

Several features of the Terminal Handler have 
been incorporated specifically to facilitate interac- 
tion with the debugger. Because of this interaction, 
the Terminal Handler is required for operation of 
the debugger. 

DISK FILE SYSTEM 

The Disk File System (DFS) provides users of 
RMX/80 with disk file management capabiUties. 
This system allows user tasks to create, access, and 
maintain disk files in a real-time environment. This 
means that many I/O requests can be processed 
concurrently, rather than one at a time. 

In addition to the file handling services, DFS pro- 
vides a program loading facility that allows you to 
load program segments into memory from disk. 

The DFS can be configured to include only those 
functions which you require. For example, if 
your disk accesses are sequential rather than 
random, you omit the SEEK function. This philo- 
sophy of minimizing memory requirements by 
including only the functions your application re- 
quires is found in virtually all aspects of RMX/80. 

DEBUGGER 

An environment that is continually changing in 
response to asynchronous physical events can pre- 
sent a serious debugging challenge. The Debugger 
aids you in debugging tasks running under the 
RMX/80 executive. The Debugger provides a 
command language that can be used to passively 
display information about the system, or actively 
modify and interact with the system. 

Passive Functions 

Because RMX/80 manages a fairly complex set of 
data structures, the Debugger has the capability 
of displaying them in an intelligible format. The 
Debugger can be used in this manner to view 
tasks, exchanges, messages, and other data struc- 



tures maintained within the RMX/80 environment. 
The contents of all RAM and ROM memory loca- 
tions may also be displayed by the Debugger. 

Active Functions 

The active Debugger functions include those of 
modifying memory, setting breakpoints, and moni- 
toring stack overflow. The memory modification 
commands enable you to update the contents of 
memory and to move a series of bytes from any 
location to any other location. 

Breakpoints can be set, allowing you to gain con- 
trol when encountered by a task. Two kinds of 
breakpoints are supported: execution breakpoints 
and exchange breakpoints. An execution break- 
point can be placed at any instruction within read/ 
write (RAM) memory. When the breakpoint is 
reached, the task encountering the breakpoint is 
stopped from further execution. The task registers 
may then be examined and modified before resum- 
ing execution. 

Exchange breakpoints can be used to detect 
RQSEND and/or RQWAIT operations performed 
on specified exchanges. The exchange breakpoint 
can thus enable you to monitor the activity of any 
of the exchanges in your system. The task execut- 
ing the appropriate RQSEND or RQWAIT to an 
exchange which has a breakpoint is stopped, allow- 
ing you to examine the task. This enables you to 
breakpoint a ROM resident task. The breakpointed 
task and the message involved in the operation 
with the exchange may then be displayed and 
modified before resuming execution. 

The debugger can also be used to monitor stack 
overflow. This function is provided by the De- 
bugger SCAN command which examines the stacks 
of all tasks in the system at a specified periodic 
interval. The fact that each task's stack is initiahzed 
with a unique value allows stack overflow to be 
detected. When a task stack overflows, it is re- 
moved from the system and a message is displayed. 

USING RMX/80 

This section of the application note describes the 
steps involved in using RMX/80. The process 
begins with the definition of the individual tasks 
and exchanges in your appUcation. It continues 
with a discussion of the data structures that you 
must prepare. The task coding, compilation or 
assembly, linking, and locating is also described. 
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Finally, some comments are directed towards de- 
bugging tasks within the RMX/80 envirnment. 

Before the details of using RMX/80 are discussed, 
some general observations are necessary to deter- 
mine the suitabihty of RMX/80 for your applica- 
tion. To effectively utilize RMX/80, your applica- 
tion must either use interrupts or require device 
polling. Thus, the key element is the need to 
respond to external events. If your apphcation 
satisfies this criteria, it is a likely candidate. How- 
ever, you must then determine if RMX/80 is capa- 
ble of supporting your apphcation. This can be 
done by examining your interrupt response time 
and frequency requirements. The time required to 
transform an interrupt into a message that is sent 
to an interrupt exchange is approximately 800 
microseconds for an SBC 80/20. This is the 
RMX/80 interrupt latency. It can be reduced to 
60 microseconds by handling the interrupt directly, 
using the RQSETV operation to bypass the 
RMX/80 interrupt exchange mechanism. In this 
latter mode, an interrupt-driven asynchronous 
block transfer rate of about 10 kHz can be achieved. 



TASK AND EXCHANGE DEFINITION 

The initial design step for an application that runs 
under the RMX/80 Executive is to define your 
tasks, exchanges, and the interaction between 
them. This is perhaps best accomplished using the 
graphic notation introduced earlier in the section 
on Send — Wait Interaction. The graphic notation 
provides a clear picture of the relationships be- 
tween the tasks and exchanges in your system. 
You can begin either in a top-down or bottom-up 
fashion. That is, you can use a top-down approach 
to define, at a gross level the operation of your 
system and then gradually break it down to the 
individual tasks. Or, you can start with the tasks 
associated with the external events in your appli- 
cation and then build the pieces to form the gross 
structure of your system. 

The bottom-up approach forces you to begin with 
external events that drive your system. The num- 
ber of these events, the amount of processing 
required, and the relationships between them 
define the tasks and exchanges in a system. For 
example, consider a system that samples an analog 
input with an A/D converter. Assume that the A/D 
provides an interrupt at the completion of a con- 
version. To use the data from the A/D converter it 
may also be necessary to scale it and add an offset. 



With this information the portion of the task and 
exchange definition that relates to this function 
can be constructed. 

Begin with the external event, the interrupt from 
the A/D. An 'interrupt priority level must be as- 
signed to the A/D converter. This same level will 
be used by the task which waits on the interrupt 
exchange. 

The relationship between the interrupt exchange 
and the A/D task is shown in Figure 11. If pro- 
cessing must be performed on raw data from the 
A/D, a second, lower priority, task could be used. 
Another task for this function will require a syn- 
chronizing signal from the ADC task to indicate 
that raw A/D data has been obtained and is ready 
for processing. 




Figure 11. Interrupt Exchange and A/D Task 



The interaction between the ADC task and the 
CONV task that processes the raw A/D data is 
shown in Figure 12. Two exchanges provide 
synchronization. The ADC task uses the TRGR 
exchange to signal that data is ready for process- 
ing by the CONV task. The CONV task uses the 
RTRGR exchange to signal the completion of its 
processing and thus its readiness to accept more 
raw data. 




Figure 12. ADC and CONV Task Interaction 
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In this example two tasks and three exchanges 
have been defined. To develop an entire system, 
the tasks and exchanges associated with all of the 
external events in the system can be defined in 
the same manner. Then, proceeding bottom-up, 
the next step is to define the tasks and exchanges 
required to support the interaction between tasks 
running at the level of the real-time events. 

After defining the entire appHcation, you can begin 
actual coding of the tasks. You may choose to 
code in either assembly language or the PL/M 80 
high-level language. Where possible, it is desirable 
to code in PL/M because PL/M lends itself to 
structured programming. Assembly language often 
encourages an ad hoc approach. Even if your appli- 
cation ultimately requires assembly language coding 
because of critical time and/or space parameters, 
initial design work in PL/M followed by transla- 
tion into assembly language is recommended. 

A total of 15 operations are supported by the 
RMX/80 nucleus. Only two of the operations, 
RQSEND and RQWAIT, are described in any detail 
in this apphcation note. The remaining operations 
are described in the RMX/80 User's Guide. The 
reason for presenting only the send and wait opera- 
tions is because they are sufficient for the imple- 
mentation of a large number of real-time applica- 
tions. These two operations provide a great deal of 
power and flexibility, yet their simplicity should 
enable those who are new to real-time program- 
ming to quickly develop applications. 

PRIORITY ASSIGNMENT 

The relative priority of tasks within a system run- 
ning under RMX/80 determines which task is to 
be executed. Therefore, the assignment of a pri- 
ority to each task is extremely crucial. For exam- 
ple, consider a compute bound task placed at a 
higher priority than an interrupt-driven task 
responsible for servicing an I/O device. This im- 
proper assignment of priorities could result in 
missed interrupts from the I/O device. Several 
steps can be followed in the assignment of task 
priorities. 

1. Assign hardware interrupt priority levels 
according to the requirements of your appli- 
cation. 

2. Specify priorities for the tasks which service 
the interrupts. These tasks should generally 
be short and serve only to perform the data 



transfers. A second task with a priority lower 
than those assigned to the hardware inter- 
rupts should be used where further processing 
of the data is required. 

3. Priority assignment should be made for all 
other tasks in the system based on the relative 
importance and interaction among the tasks. 

Unfortunately the last step in assigning task pri- 
orities is largely intuitive. In fact, you may need 
some empirical data from actually running your 
appHcation before you settle on your final task 
priority assignment. 

STATIC DESCRIPTORS 

When a system running under RMX/80 begins 
execution, several tables of data are used to ini- 
tialize the system. These tables usually reside in 
ROM. The first table is the create table (RQCRTB) 
that specifies the number of tasks and exchanges 
in the system, and the addresses of the initial 
task table and the initial exchange table. The ini- 
tial exchange table contains the addresses of all 
the exchange descriptors. The initial task table 
contains the static task descriptors for each task, 
and contains the following task parameters. 

1 . Name 

2. Initial PC — the location at which' to start 
task execution 

3. Initial SP — the location at which to start 
the task stack 

4. Stack length 

5. Priority 

6. Initial Exchange (described in the RMX/80 
User's Guide) 

7. TD Address — the RAM address of the task 
descriptor 

You must prepare all three of these tables to pro- 
duce a configuration module for RMX/80. The 
release diskette for RMX/80 includes a set of files 
which contain assembly language macros that sim- 
pHfy the preparation of your configuration module. 
The relationship between these tables is shown in 
Figure 13. 



COMPILATION/ASSEMBLY 

Preparing program segments for compilation and 
assembly can be simpHfied by use of files provided 
on the RMX/80 diskette. As described in the last 
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section, a set of macros is included to assist you in 
preparing your configuration module. Other files 
are provided that are useful when coding calls to 
RMX/80 and preparing data structures in PL/M. 



ITT POINTER 


> 


-^ 


STD1 
STD2 

• 
STDn 






EXCHANGE-ADDRESS-1 
EXCHANGE-ADDRESS-2 

• 
EXCHANGE-ADDRESS-n 


TASK 1 
COUNT 1 




lET POINTER 


h 




EXCHANGE 1 
COUNT 1 

















Figure 13. ROM Based Tables 



By coding in a modular fashion you can separately 
compile and maintain tasks. This is advisable since 
a single large module containing all your tasks 
would require a lengthy recompilation to change 
any one of the tasks. Following the compilation 
and assembly of your source code modules, a 
hbrary containing the object modules can be 
created. 

LINKING 

The process of hnking prepares a single object mo- 
dule from libraries containing the RMX/80 object 
modules and your own application libraries or se- 
parate object modules. The order in which you 
specify the files to be linked is crucial to successful 
linking. In general, your libraries or separate object 
modules should be specified before the RMX/80 
Hbraries. The link command should conclude with 
the unresolved library (UNRSLV.LIB) that con- 
tains miscellaneous modules for resolving PUBLICS 
not used in the appHcation code. PUBLICS extend 
the scope of variables to allow linkage between 
separate program modules. Figure 14 illustrates 
how an appUcation program is linked from RMX/80 
and user tasks. 

LOCATING 

It is appropriate in this section to give some guide- 
lines regarding the assignment of RAM and ROM 
address space for your Single Board Computer 
environment. The SBC 80 Single Board Computers 
have ROM based at location 0. Since the LOCATE 
program places all code in a contiguous block, the 
code must begin at location 0. Likewise, the read/ 
write (RAM) data is also placed in a contiguous 
block. The base address of data should be placed 
at your RAM base address. Depending on the 



amount of code space required by your appUca- 
tion it may be necessary to move the RAM mem- 
ory base address on your SBC to a higher location. 
A STACKSIZE of zero should be specified because 
you allocate stack for each RMX/80 task in the 
static task descriptors. 

DEBUGGING 

As mentioned in the overview of the RMX/80 De- 
bugger, the real-time environment is a complex 
one in which to debug your programs. Intel pro- 
vides two tools that you can use for debugging. 
The RMX/80 Debugger and the Intel In-Circuit 
Emulator (ICE). It is desirable to have both of 
these debugging tools at your disposal. 




Figure 14. RMX/80 Linking 



ICE enables you to use Intel Microcomputer Devel- 
opment System memory in place of SBC 80 mem- 
ory. This allows RAM residency during your debug- 
ging as opposed to programming PROMs for each 
iteration. Your system may initially fail before the 
RMX/80 Debugger can begin operation. In this 
situation ICE can be used to debug your program. 



APPLICATIONS 

RMX/80 is suitable for a wide variety of appUca- 
tions. Two specific examples are presented in this 
application note. Each example illustrates the 
steps involved in using RMX/80 and provides a 
detailed description of the coding itself. 

MINIMAL TERMINAL HANDLER 

The basic functions required for a terminal handler 
are well defined. The handler must respond to 
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operator input, transmit output characters, and 
echo characters as they are entered. This appHca- 
tion note describes one implementation of a mini- 
mal terminal handler. 

The terminal handler presented here is not the 
RMX/80 Terminal Handler. It does provide some 
common functions and uses the same exchanges 
and message formats. However, many features 
of the RMX/80 Terminal Handler have been left 
out. Omitted features include special hooks to run 
with the Debugger, an alarm exchange, control S, 
Q, and O operations. 

As described in the chapter on using RMX/80, the 
process of developing an RMX/80 application be- 
gins with the definition of the tasks and exchanges. 
The graphic notation is used to prepare a diagram 
(Figure 15) showing the tasks, exchanges, and their 
interaction. 



waits on the RQL7EX to determine when charac- 
ters can be sent to the USART. 

The following Usting* shows the RDMIN and 
WRMIN tasks. These tasks provide a minimal ter- 
minal handler. The program is written in PL/M. 
The WRMIN task is also presented in assembly 
language in Appendix B. The program hsting is 
interspersed with explanatory text. The program 
begins with the program segment label "MINI- 
MAL$TERMINAL$HANDLER:" and a DO state- 
ment. 

1 MI^^MALSTtk^lINAL$HANDLEk: 



Several macros are declared using the reserved 
word LITERALLY. These macros are expanded 
at compile time by textual substitution. 




Figure 15. Minimal Terminal Handler 



As shown in Figure 15, the RDMIN task waits 
on the RQINPX exchange for input requests. The 
RDMIN task also successively waits on the RQL6EX 
and RQL7EX exchanges. It uses the RQL6EX 
exchange to determine when a character has been 
received by the USART. The RQL7EX exchange 
is used to indicate when the transmitter is ready 
to accept another character. RDMIN uses RQL7EX 
for echoing input characters. 

The WRMIN task waits on the RQOUTX exchange 
for output requests. When it receives a request, it 



/* SPECIAL ASCII CHARACTERS V 


DECLARE 






BELL 


LITERALLY 


•07H', 


LF 


LITERALLY 


'0AH*, 


CR 


LITERALLY 


•BDH', 


CONTROLSH 


LITERALLY 


•12H', 


CONTKOLSX 


LITERALLY 


■leH", 


ESC 


LITERALLY 


'IBH', 


RUBOUT 


LITERALLY 


•7FH'; 



Some macros are used to simpHfy the declaration 
of RMX/80 data structures. The structures de- 
clared here are for the exchange descriptor, inter- 
rupt exchange descriptor, and the messages used 
by the minimal terminal handler. 



DECLARE EXCHANGE$DESCRIPTOR LITERALLY .'STRUCTURE ( 
MESSAGE$HEAD ADLRESS, 
MESSAGESTAIL ADDRESS, 
TASK?HEAD ADDRESS, 
TASKSTAIL ADDRESS, 
EXCHANGE$LINK ADDRESS)'; 

DECLARE INTSEXCHANGE$DESCRIPTOR LITERALLY 'STRUCTURE 
MESSAGESHEAD ADDRESS, 
MtSSAGE$TAIL ADDRESS, 
TASKSHEAD ADDRESS, 
TASK$TAIL ADDRESS, 
EXCHANGE$LINK ADDRESS, 
LINK ADDRESS, 
LENGTH ADDRESS, 
TYPE BYTE) '; 

DECLARE ThSHSG LITERALLY 'STRUCTURE ( 
LINK ADDRESS, 
LENGTH ADDRESS, 
TYPE BYTE, 

hOME$EXCHANGE ADDRESS, 
RLSPONJE$EXChANGb ADDRESS, 
STATUS ADDRESS, 
BUf'FER$ADDRESS ADDRESS, 
COUNT ADDRESS, 
ACTUAL ADDRESS) ' ; 



The following macros are specifically for the SBC 
80/20. The macros require changes to run the 
minimal terminal handler on a different Single 
Board Computer. Intel 8253 timer/counter and 
8251 USART chips are used. 



*Full size listings in Appendixes A and C. 
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8253 PORT ADDRLSStS. 



825 3 COMMANDS. 
*/ 

DECLARE SELECTS2 LITERALLY 'lUBH00O0B'i 
DECLARE RL$BOTH LITERALLY '00110000B'i 
DECLARE M0DES3 LITERALLY ' 00000I10B ' ; 
DECLARE B2400 LITERALLY •001CH'; 



8251 PORT ADDRESSES. 

V 

DECLARE USARTSIN LITERALLY 'BECH', 
USARTSOUT LITERALLY 'BECh', 
USARTSCONTROL LITERALLY •0EDh' 



8251 MODES. 
V 

DECLARE ST0P$1 LITERALLY '010000006'; 
DECLARE CL8 LITERALLY ' 00001100B ' ; 
DECLARE RATESI6X LITERALLY '000000108'; 



Tasks coded in PL/M take the form of parameter- 
less PUBLIC procedures. The procedure declara- 
tion is followed by the variables used in RDMIN. 
MSGPTR receives the address of an input request 
message. The based-variable MSG accesses the 
data in the input request message. INTMSG is a 
dummy variable which simply receives the address 
of the interrupt message. BUF$ADDRESS points 
to the buffer where the input characters are to be 
placed. The BUF array is based at the buffer 
pointed to by BUFSADDRESS. 



8251 COMMANDS. 



DECLARE USART$R£SET 


LITERALLY 


01000000B 


RTS 


LITERALLY 


00100000B 


ERROR$RESLT 


LITERALLY 


00010000B 


RXE 


LITERALLY 


00000100B 


DTR 


LITERALLY 


00000010B 


TXEN 


LITERALLY 


00000001B 



PROCEDURE PUBLIC; 

DECLARE (MSGPTR, INTMSG, BUFSADDRESS) ADDRESS; 

DECLARE (CHAR,PTR,I) BYTE; 

DECLARE MSG BASED MSGPTR THSMSG; 

DECLARE (BUF BASED BUFSADDRESS) (1) BYTE; 



RDMIN and WRMIN call three RMX/80 opera- 
tions. They are RQSEND, RQWAIT, and RQELVL. 
RQSEND and RQWAIT allow tasks to send and 
receive messages from exchanges. RQELVL enables 
a specific interrupt level. 



The RDMIN task echoes characters after they are 
read in. The ECHO$CHAR procedure performs this 
function. It waits for a level 7 interrupt, indicating 
that the transmitter is ready for another character. 
ECHO$CHAR then transmits the character. 



K(jSEND: 

PROCEDURE (EXCHANGESPOINTER,MESSAGESPOINTER) EXTERNAL; 

DECLARE (EXCHANGESPOINTER,MESSAGESPOINTER) ADDRESS; 
END RUSEND; 

R(jWAn: 

PROCEDURE (EXCHANGESPOINTER, DELAY) ADDRESS EXTERNAL; 

DECLARE (EXCHANGESPOINTER, DELAY) ADDRESS; 
END RwWAIT; 

KUtLVL: 

PROCEDURE (LEVEL) EXTERNAL; 

DECLARE LEVEL BYTE; 
END RwELVL; 



The exchange descriptors and interrupt exchange 
descriptors must be PUBLIC because they are 
referenced by the configuration module. 



EChOSCHAR: 

PROCEDURE (CHAR) ; 

DECLARE CHAR BYTE; 

INTMSG = RQUAIT(.fiQL7£X,0) ; 

OUTPUT (USARTSOUT) = CKAR; 
END ECHOSCHAR; 



Execution of the RDMIN task starts with the next 
statement, a call to the initialization procedure. 
This call is followed by two calls to the procedure 
which will enable interrupt levels 6 and 7. 



CALL INITIALIZATION; 



The following procedure initiaHzes the 8253 and 
8251 (USART). The 8253 generates the baud rate 
clock (2400 baud in this example). The program 
sends four nulls to the USART control port to 
ensure that the USART is ready for a command, 
no matter what state it was previously in. The pro- 
gram then sends a reset command to the USART, 
followed by the mode and another command. 



The basic structure of an RMX/80 task is that of 
a program with an imbedded infinite loop. This 
loop starts with the DO FOREVER statement. 
In the continuous loop, the task waits for an input 
request message. This wait is satisfied when some 
other task in the system sends an input request 
message to the RQINPX exchange. The based 
variable used to point to BUF is assigned from a 
field in the input request message, MSG.BUF- 
FERSADDRESS. An index for the BUF array, 
PTR, and the variable CHAR are initialized. 



INITIALIZATION: 
PROCEDURE; 

OUTPUT (A8253SMODE) » SELECT$2 OR 

OUTPUT(A8253$CTR2) =LOW(B2400)j 

OUTPUT(A8253SCTR2) = hIGH{B24M0) 

OUTPUT (USARTSCONTROL) , 

OUTPUT (USARTSCONTROL) , 

OUTPUT (USARTSCONTROL) , 

OUTPUT (USARTSCONTROL) 

OUTPUT (USARTSCONTROL) 

OUTPUT (USARTSCONTROL) 

OUTPUT (USARTSCONTROL) 



RLSBOTH OR MODES 3; 



END INITIALIZATION; 



USARTSRESET; 

STOPSl OR CL8 OR RATES16X; 
RTS OR ERRORSRESET OR 
RXE OR DTR OR TXEN; 



DO FOREVER; 

MSGPTR = ROl«iAIT(.ROINPX,0) ; 
BUFSADDRESS = MSG.BUFf ERSADDRESS - 1; 
PTR = 0; 
CHAR = NOT CK; 



Task execution continues inside the next loop 
until a carriage return (CR) is input. An escape 
character (ESC) within the loop simulates a CR 
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which enables an exit from the loop. The task 
simply waits on the RQL6EX exchange for a mes- 
sage." This amounts to an interrupt service routine. 
When the wait is satisfied, the USART has received 
a character. 



The character is then placed in the buffer unless 
the end of the buffer has been reached. If the 
buffer is full, a BELL is sent to the terminal. 



The next statement performs a whole series of 
operations. The character input from the USART 
is logically ANDed with 7FH to mask off the parity 
bit, assigned to the variable CHAR, and tested to 
determine if it is a RUBOUT character. If a RUB- 
OUT is found, either a BELL is echoed to the ter- 
minal if there are not characters to delete in the 
buffer (PTR = 0), or the last character in the 
buffer is echoed and the pointer is decremented. 



The last test is for an ESC character. It is echoed as 
a "$" and is treated as if a CR were entered. 



F (CHAR 


:= INPUT (USARTSIN) 


IF PTR 


= THEN 


CALL 


EChOSCHAR(BELL) ; 


ELSL 




DO; 




CALL 


ECHOSCHAR(BUF{PTR)) 


PTR = 


PTR - 1; 


END; 





= RUBOUT THEN 



If CHAR is not a RUBOUT, it is tested for a 
CONTROLSX. The function of a CONTROL$X 
is to delete the entire Hne by resetting PTR to 
zero. After deleting the line, the system prompts 
the operator with a "#" character and is ready to 
accept a new line. 



IF CHAR = CONTROLSX THEN 
DO; 

CALL ECHO$CHAR('r) ; 

CALL ECHO$CHAR(CR) ; 

CALL £CHO$CHAR(LF) ; 



The next test determines if CHAR is a CON- 
TROL$R. CONTROLSR echoes the entire line 
that has been entered. This function is useful for 
displaying a line containing anumberof RUBOUTs. 
Such lines can be difficult to interpret because 
RUBOUT echoes deleted characters. Because 
CONTROL$R echoes only the remaining data 
in the buffer, it eliminates "garbage" from the 
display. 



IF ChAK = CONThOLSR THEN 
DO; 

CALL ECHO$ChAh(Ch) ; 

CALL tCHOSCHAR(LF) ; 

DO 1 = I TO PTK; 

CALL tCHU$CHAk(BUF(I) ) 

END; 
END; 



IF CrtAk = EbC THEN 
DO; 

CALL ECHOSCHAK( 'S') 
ChAK = CR; 
END; 

CALL ECHUSChAR(CHA^) ; 
END; 
END; 



The program places a line feed (LF) at the end of 
the buffer when an exit is forced by a CR or an 
ESC. The input request message actual character 
count (MSG.ACTUAL) and the status (MSG. 
STATUS) are set before sending the message to 
its response exchange. 



If PTR < MSG. COUNT THEN 
BUF(PTR:=PTR+1) = LF; 
MSG.ACTUAL = PTR; 
MSG. STATUS = 0; 

CALL R(jSEND(MSG.RESPONSE$EXCnANGE,MSGPTR 
CALL ECHU$CHAR(LF) ; 
END; 
END RDSMIN; 



The WRMIN task begins by enabling interrupt 
level 7. Note that no other initialization is per- 
formed before WRMIN waits for an output request 
message to arrive at the RQOUTX exchange. Here 
correct operation depends on the fact that RDMIN 
has a higher priority than WRMIN. Were this not 
the case, WRMIN could try to transmit a message 
before the 8253 and 8251 have been set up. 



PROCEDURE PUBLIC; 

DECLARE (MSGPTR,INTMSG,BUFSADDRESS) ADDRESS; 

DECLARE PTR BYTE; 

DECLARE MSG BASED MSGPTR TH$MSG; 

DECLARE (8UF BASED BUF$ADDRESS) (1) BVTE; 

CALL RUELVL(7) ; 

DO FOREVER; 

MSGPTR = RQWAIT(.RQOUTX,0) ; 
BUFSADDRESS = MSG. BUFFER$ADDRESS - 1; 



The next loop transmits all of the characters speci- 
fied by the output request message. Once again, 
the interrupt service routine is implemented by 
simply waiting on the RQL7EX exchange for a 
transmitter ready interrupt message. When this 
message is received, the next character in the 
buffer is transmitted. 



2-17 



DO PTR = 1 TO MSG.CCUNl; 

INTMSG = fiOhAIT(.ROL7tX,0) ; 

OUTPUT (USAftTSOUT) = BUF(PTR); 
END; 



The WRMIN task concludes by setting the actual 
count and status, and then sends the output re- 
quest message to its response exchange. 



MSG. ACTUAL •= MSG. COUNT; 
MSG. STATUS = B; 

CALL RQStND(MSG.RESPONSt$E;XChANGE,MSGPTf<) ; 
ENC; 
END WR$MIN; 



Using the macros provided on the RMX/80 dis- 
kette, the following static task descriptors (STD) 
should be placed in your configuration module. 



STD 
STD 



RDMIN,64,112,0 
WRMIN,64,128,0 



The entries in the STD are interpreted as follows. 

STD NAME,STKLEN,PRI,EXCH 

where: 



This can easily be accomplished by sending several 
input requests to the RQINPX. These input 
requests have the address of a "full-buffer" ex- 
change as the response exchange and the RQINPX 
exchange as the home exchange. Then, tasks need- 
ing terminal input wait on the "full-buffer" ex- 
change and send the message to the home exchange 
when finished. 

CLOSED-LOOP ANALOG CONTROL 

In the next example, a closed-loop analog control 
subsystem using the Intel SBC 711 analog-to- 
digital board illustrates task scheduling and syn- 
chronization in a process control application. In 
general, the subsystem samples an analog input at 
specified intervals, converts the data to temperature 
in degrees centigrade, and then — based upon pro- 
grammed temperature limits - controls a heating 
element. The algorithm used provides a 2-position 
controller with neutral intermediate zone (or sim- 
ply "bang-bang" control). The control algorithm 
is shown in Figure 1 6. 



NAME = the symbolic name assigned to the tasl< asso- 
ciated with the STD 

STKLEN = the number of bytes allocated to the task 
stack 

PR I = the task priority level 

EXCH = an optional field, usually 

Priorities of 112 and 128 have been assigned to 
RDMIN and WRMIN because they correspond to 
hardware interrupt levels 6 and 7. 

The following exchange addresses should be 
placed in your configuration module. 



POSITION 1 
(ON) 



POSITION 2 
(OFF) 



^ 



^SWITCHING POINTS 



*^ 



V. 



■ TEMPERATURE 



Figure 16. 2-Position Controller with Neutral Intermediate 
Zone 



The graphic notation in Figure 17 diagrams the 
tasks, exchanges, and their interaction. 



XCHADR 
XCHADR 
XCHADR 



RQINPX 

RQOUTX 

RQL6EX 



XCHADR RQL7EX 

The XCHADR macro only requires the address of 
the exchange descriptor. 

Characters typed at the terminal are ignored unless 
an input request message has been received. Thus, 
type-ahead is not a built-in feature. However, 
if type-ahead is desired, it is sufficient to ensure 
that input requests are always queued for the 
RDMIN task and that the full input buffers are 
sent to an exchange that queues full buffers. 
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This application includes three tasks and six asso- 
ciated exchanges. The TICKER task schedules 
the ADC task. TICKER has a very high priority 
because nothing else in the system should inter- 
fere with its scheduling activities. It is also a very 
short task since it repetitively executes a timed 
wait and then handshakes a message. 

TICKER schedules the ADC task. The ADC task 
services the A/D converter. After obtaining data 
from the A/D it handshakes with the CONTROL 
task to signal that data is ready for processing. 
The ADC task is assigned a priority equivalent 
to the level of the hardware interrupt from the 
A/D. Clearly, calculations should not be performed 
at that priority. 

Thus, CONTROL performs the processing function 
at a lower priority. The CONTROL task used the 
T$PARAM$LOCK exchange to govern access to 
the control parameters. This avoids problems re- 
sulting when some other task is updating the pa- 
rameters at the same time the CONTROL task is 
using them for testing. 





2 


END RQENDI; 








2 


HQELVL: 

PROCEDURE (LEVE 
DECLARE LEVEL 


) EXTERN 
BYTE; 


AL; 




2 


END ROELVL; 








;, 


RQDLVL: 

PROCEDURE CLEVE 
DECLARE LEVEL 


) EXTERN 
BYTE; 


AL; 




2 


END RODLVL; 








2 


ROSETV: 

PROCEDURE (PROC 
DECLARE PROC 


LEVEL) F 
DDRESS; 


XTER 




2 
2 


DECLARE LEVEL 
END ROSETV; 


BYTE; 





26 2 

27 2 



29 2 

30 2 



32 2 

33 2 



$INCLUDE( :F1 :SYNCH.EXT) 
ROSEND: 

PROCEDURE ( EXCHANGEtPOINTEB ,ME33AGE»P0INTER) EXTERNAL; 
DECLARE ( EXCHANGE$POINTER,MESSAGE$POINTER) ADDRESS; 

END ROSEND; 

ROWAIT: 

PROCEDURE ( EXCHANGE$POINTER,DflAY) ADDRESS EXTERNAL; 
DECLARE ( EXCHANGE$P0INTER,5ELAY) ADDRESS; 

END ROWAIT; 

ROACPT: 

PROCEDURE ( EXCHANGE$POINTER) ADDRESS EXTERNAL; 
DECLARE EXCHANGEtPOINTER ADDRESS; 



RQISND: 

PROCEDURE (IED$PTR) EXTERNAl 
DECLARE IED$PTR ADDRESS; 

END RQISND; 



Additional macros are declared to aid in the use 
of the SBC 71 1 analog-to-digital board. 



As in the minimal terminal handler, the following 
listing contains the complete analog subsystem 
tasks and is interspersed with explanatory text. 
The program begins with the program segment 
label "ATOD:" and a DO statement. 



SBC 711 AN, 



LOG TO Dior 



DECLARE ADC$BASE ADDRESS AT (0F700H); 
DECLARE COMMAND$REGISTER BYTE AT ( . ADC$ BASE* ) ; 
DECLARE STATUStREGISTER BYTE AT ( . A DC$ BASE + ) ; 
DECLARE FIRST$CHANNEL$RECISTER BYTE AT C . ADC$BASE+ 1 ) ; 
DECLARE LAST$CHANNEL$REGISTER BYTE AT C . A DC$ BASE+2 ) ; 
DECLARE CLEAR$INTERRUPT$REOUEST BYTE AT ( . ADC$BASE* 3 ) ; 
DECLARE ■ADC$DATA$FEGISTER ADDRESS AT ( . A DC$ BASE + 14 ) ; 



DECL 


IRE 


GO$BIT LITERALLY ' T ; 


DECL 


^RE 


AUTO$INCREMENT$ENABLE LITERAL 


DECL 


RE 


BUSY LITERALLY '8' ; 


DECL 


RE 


EOS$INTERRUPT$ENABLE LITERALL 


DECL 




EOC$INTERRUPTiENABLE LITERALL 


DECL 


RE 


END$OF$SCAN LITERALLY 'UOH'; 


DECL 


RE 


END$OF$CONVERSION LITERALLY * 



The macros and externals used in this module 
are brought in by means of INCLUDES from the 
RMX/80 diskette. 



The exchange descriptors and the interrupt ex- 
change descriptors are declared. 



LLY 'STRUCTURE ( 



$INCLUDE(:F1 : COMMON. ELT) 
DECLARE TRUE LITERALLY 'OFFH"; 
DECLARE FALSE LITERALLY 'OOH'; 
DECLARE BOOLEAN LITERALLY 'BYTE'; 
DECLARE FOREVER LITERALLY 'WHILE 

$INCLUDE( :F1 :EXCH.ELT) 

DECLARE EXCHANGE$DESCRIPTOR LITEl 

MESSAGE$HEAD ADDRESS, 

MESSAGE$TAIL ADDRESS, 

TASK$HEAD ADDRESS, 

TASK$TAIL ADDRESS, 

EXCHANGE$LINK ADDRESS)'; 



$INCLUDE( :F1 :IED.ELT) 

DECLARE INT$EXCHANGE$DESCRIPTOR LITERALLY 'STRUCTURE { 

MESSAGE$HEAD ADDRESS, 

MESSAGE$TAIL ADDRESS, 

TASK$HEAD ADDRESS, 

TASK$TAIL ADDRESS, 

EXCHANGE$LINK ADDRESS, 

LINK ADDRESS, 

LENGTH ADDRESS, 

TYPE BYTE) ' ; 

$INCLUDE( :F1 :MSG.ELT) 
DECLARE MSG$HDR LITERALLY ' 

LINK ADDRESS, 

LENGTH ADDRESS, 

TYPE BYTE, 

HOME$EXCHANGE ADDRESS, 

RESPONSEtEXCHANGE ADDRESS' ; 

DECLARE MSG$DESCRIPTOR LITERALLY 'STRUCTUREC 

MSG$HDR, 

REMAINDER( 1) BYTE)' ; 
$INCLUDE( :F1 :INTRPT.EXT) 
ROENDI: 

PROCEDURE EXTERNAL; 



DECLARE DUMMY EX CH ANGE$DESCRI PTC R PUBLIC; 
DECLARE FET$PULSE EXCH ANG E$ DESC RI PTO R PUBLIC; 
DECLARE GO$PULSE EXCHANGE$ DESC RI PTOR PUBLIC; 
DECLARE TRIGGER EXCH ANG E$ DESC RI PTOR PUBLIC; 
DECLARE RET$TRIG EX CH ANGE$ DESCRI PTO R PUBLIC; 
DECLARE R0L2EX INT$ EXCH ANGEtDESC RI PTOR ; 



The CONTROL task uses an external data struc- 
ture to obtain operating parameters. This data 
structure (BOX$PARAMS) has an exchange asso- 
ciated with it (T$PARAM$LOCK) that is used to 
provide mutual exclusion, ensuring that only one 
task accesses the data structure at a time. 



,ARE T$PARAM$LOCK EXCH ANGE$ DESC R I PTO R 

.ARE B0X$PARAMS{5) STRUCTURE( 
CHANNEL BYTE, 
SET$POINT ADDRESS, 
ERROR ADDRESS, 
OFFSET ADDRESS, 
SAMPLES ADDRESS, 
COUNT ADDRESS, 
ACCUM ADDRESS, 
READING ADDRESS ) EXTERNAL; 
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TICKER, the scheduler task, has an initiaHzation 
sequence in which it sets up two messages and 
sends them to the RET$PULSE exchange. Then it 
enters an infinite loop where it waits on the 
DUMMY exchange for 250 milliseconds. After 
the timed wait is complete, TICKER passes a mes- 
sage from the RET$PULSE exchange to the G0$- 
PULSE exchange. In effect this is a handshake, 
checking to see that the ADC task has completed 
its last operation and then signaling it to perform 
another. 



The CONTROL task waits for a message from the 
ADC task signaling that A/D readings have been 
taken and are ready for further processing. It com- 
pletes the handshake by sending the message to 
the RET$TRIG exchange. Then, as in the ADC 
task, accesses the BOXSPARAMS data structure. 

Inside the next loop, the readings are averaged, 
scaled, offset, and tested. Appropriate action is 
taken to turn the heating elements on or off. The 
loop concludes by returning the message to the 
T$PARAM$LOCK exchange. 



:ZE(PULSE$MSG(0 



TICKER$TASK: 

PROCEDURE PUBLIC; 

DECLARE MSG ADDRESS; 
DECLARE PULSE$MSG(2) STRUCTURE ( 
MSG$HDR ) ; 

PULSE$MSG(0) . LENGTH, 

PULSE$MSG( 1) .LENGTH = 

PULSE$MSG(0) .TYPE, 

PULSE$«SG( 1) .TYPE = 65; 

CALL RQSEND(.RET$PULSE,.PULSE$MSG(0)); 

CALL R0SENDC.RET$PULSE,.PULSE$MSG(1)); 

DO FOREVER; 

MSG - ROWAITC . DUMMY, 5) ; 
MSG = RQWAIT( .RET$PULSE,0) ; 
CALL RQSENDC .GO$PULSE,MSG) ; 



END ticker$ta; 



Scheduled by TICKER, the ADC task performs the 
A/D sampling. It begins by setting up TRIGGER$- 
MSG and enabling the level 2 interrupt from the 
A/D. Inside the ADC task continuous loop, mes- 
sages are passed from the GO$PULSE exchange to 
the RET$PULSE exchange. Then it waits for ac- 
cess to the BOXSPARAMS data structure. When 
the ADC task has access, it loops through the A/D 
channels, accumulating readings in BOXSPARAMS. 
After all the A/D channels are sampled and the 
BOXSPARAMS readings updated, the LOCKSMSG 
is returned to the TSPARAMSLOCK exchange. 
The ADC task concludes the continuous loop by 
handshaking a message with the CONTROL task. 



ADC$TASK: 

PROCEDURE PUBLIC; 

DECLARE TRIGGER$HSG STRUCTURE ( 

MSG$HDR ) ; 

DECLARE (T$MSG,MSG,LOCK$MSG) ADDRESS; 

DECLARE I BYTE; 

DECLARE GAIN LITERALLY '00'; 

DECLARE N$CHNLS LITERALLY '5'; 

TRIGGER$MSG. LENGTH = SI ZE ( TRIGGER$MSG ) 
TRIGGERtMSG.TYPE = 65; 

CALL RQSEND( .RET$TRIG,.TRIGGER$MSG) ; 
CALL R0ELVL(2) ; 

DO FOREVER; 

MSG = RQWAIT( .GOtPULSE.O) ; 
CALL RQSEND( .RET$PULSE,MSG) ; 
LOCK$MSG = RQWAIT( .T$PARAM$LOCK,0) ; 
DO I = TO N$CHNLS-1; 

FIRST$CHANNEL$REGISTER = BOX$PARAM; 
+ ROLCGAIl 
COMMAND$fiEGISTER = GO$flIT 

OR EOC$INTERR 
MSG = RQWAIT( .RQL2EX,0) ; 
COMMAND$REGISTER = 0; 

BOX$PARAMS(I) .ACCUM = BOX$ P AR AMS( I ! 
+ ADC$DATA$R1 
END; 

CALL RQSENDC .T$PARAM$LOCK,LOCK$MSG) ; 
T$MSG = RQWAITC .RET$TRIG,0) ; 
CALL RQSEND( .TRIGGER, T$MSG) ; 
END; 

END ADCtTASK; 



( D.CHi 
,6); 

T$ENABL1 



CONTROL$TASK : 

PROCEDURE PUBLIC; 

DECLARE ( LOCK$MSG,T,MSG) ADDRESS; 
DECLARE I BYTE; 

DECLARE NCHNLS LITERALLY '5'; 
DECLARE TURN$LAMP$ON 

LITERALLY •0UTPUT(0E7H)=SHL{I,1)' ; 
DECLARE TURN$LAMP$0FF 

LITERALLY ' OUTPUT( E7 H ) r SHL( I , 1 ) + T ; 
.DECLARE SETUP$8255 LITERALLY ' OUTPUT( 0E7 H ) = 8 
0UTPUT(0E6H)=0 
SETUP$8255; 

DO FOREVER; 

MSG = ROWAIT{ .TRIGGER ,0) ; 
CALL RQSENDC .flET$TRIG, MSG) ; 
LOCKiMSG= ROWAITC . T$ P AR AM$ LOCK , ) ; 
DO I = TO NCHNLS-1 ; 

BOX$PARAMSC I) .COUNT = BOX$ P AR AMSC I ) . COUN' 
IF BOX$PARAMSC I) .COUNT 

= BOX$PARAMSC I) .SAMPLES THEN 
DO; 
T, 

BOXtPARAMSC I) .READING 
= CBOX$PARAMSC I) .ACCUM 

/BOX$PARAMSC I) .SAMPLES) / 38 
+ BOXtPARAMSC I) .OFFSET; 
IF T <= BOX$PARAMSC I) .SET$POINT 

- BOX$PARAMSC I) .ERROR THEN 
TURN$LAMP$ON; 
ELSE 

IF T >= BOX$PARAMSC I) .SET$POINT 

+ BOX$PARAMSC I) .ERROR THEN 
TURN$LAMP$OFF; 
BOX$PARAMSC I) .ACCUM, 
BOX$PARAMSC I) .COUNT = 0; 



CALL RQSENDC . T» PAR AM$ LOCK , LOCK$MSG i 



END CONTROL$TASK; 
END ATOD; 



SUMMARY/CONCLUSIONS 

The purpose of this appHcation note is to intro- 
duce you to the Intel RMX/80, Real-Time Multi- 
tasking Executive. The general framework of 
RMX/80 was discussed, including the nucleus and 
extensions. 

This appHcation note described the steps involved 
in using RMX/80. Key emphasis has been placed 
on the need to fully define the tasks and exchanges 
in your appHcation using graphic notation. 

Applications have been presented to demonstrate 
task communication, synchronization, and mutual 
exclusion in a minimal terminal handler and an 
analog subsystem. The tasks responded to real- 
time asynchronous events such as USART and 
A/D interrupts. 

RMX/80 represents a significant step in the sophis- 
tication of microcomputer software. Its ease of 
use, flexibility, and power should enable you to 
quickly implement real-time software for your 
appHcations. 
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APPENDIX A 

MINITH PL/M LISTING 

1 MIjNiIiViAL$TERMIlSlAL$BAi\lDLER: 
DO; 

2 1 DECLARE TRUE LITERALLY '0FFH'; 

3 1 DECLARE FOREVER LITERALLY 'VvHILE TRUE ' ; 

/* SPECIAL ASCII CHARACTERS */ 

4 1 DECLARE 



BELL 


LITERALLY 


*07H' 




LF 


LITERALLY 


'0AH' 




CR 


LITERALLY 


•0DH' 




CONTROL$R 


LITERALLY 


•12H' 




COiNiTROL$X 


LITERALLY 


'18B' 




ESC 


LITERALLY 


•IBH' 




RUEOUT 


LITERALLY 


•7FH' 





5 1 DECLARE EXCHANGE$DESCRIPTOR LITERALLY 'STRUCTURE ( 

MESSAGE$BEAD ADDRESS, 
MESSAGE$TAIL ADDRESS, 
TASK$HEAD ADDRESS, 
TASK?TAIL ADDRESS, 
EXCHANGE$LIISiK ADDRESS) ' ; 

6 1 DECLARE INT$EXCBAJNiGE$DESCRIPTOR LITERALLY 'STRUCTURE ( 

MESSAGE$BEAD ADDRESS, 
]yiESSAGE$TAIL ADDRESS, 
TASK$BEAD ADDRESS, 
TASK$TAIL ADDRESS, 
EXCBANGE$LINK ADDRESS, 
LINK ADDRESS, 
LENGTH ADDRESS, 
TYPE BYTE) ' ; 

7 1 DECLARE TB$MSG LITERALLY 'STRUCTURE( 

LINK ADDRESS, 
LENGTB ADDRESS, 
TYPE BYTE, 

BOME$EXCBANGE ADDRESS, 
RESPOnSE$EXCBANGE ADDRESS/ 
STATUS ADDRESS, 
BUFFER$ADDRESS ADDRESS, 
COUNT ADDRESS, 
ACTUAL ADDRESS) ' ; 

/* 

8 25 3 PORT ADDRESSES. 

V 

8 1 DECLARE A8253$MODE LITERALLY '0DFB'; 

9 1 DECLARE A8253$CTR2 LITERALLY '0DEB'; 
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/* 

8253 COMMAIviDS, 

V 

10 1 DECLARE SELECT$2 LITERALLY '1W000000B'; 

11 1 DECLARE RL$BOTH LITERALLY '00110000B'; 

12 1 DECLARE M0DE$3 LITERALLY '00000110B'; 

13 1 DECLARE B2400 LITERALLY '001CH'; 

/* 

8251 PORT ADDRESSES. 

V 

14 1 DECLARE USART$IiSi LITERALLY '0ECH', 

USART$OUT LITERALLY '0ECH\ 
USART$CONTROL LITERALLY •0EDh'; 

/* 

8251 MODES, 
*/ 

15 1 DECLARE ST0P$1 LITERALLY '010000006'; 

16 1 DECLARE CL8 LITERALLY '000011006'; 

17 1 DECLARE RATE$16X LITERALLY '00000010B'; 

8 251 COMMANDS. 
*/ 

18 1 DECLARE USART$RESET LITERALLY '01000000B', 

RTS LITERALLY '001000006', 

ERROR$RESET LITERALLY '00010000B', 

RXE LITERALLY '00000100B', 

DTR LITERALLY '00000010B', 

TXEN LITERALLY '0000000 IB'; 

19 1 RQSEND: 

PROCEDURE (EXCHAN"GE$POINTER,MESSAGE$POIiNlTER) EXTERNAL; 

DECLARE (EXCHANGE$POIiNITER,MESSAGE$POIt\iTER) ADDRESS; 
EiSiD RgSEND; 

RgWAIT: 

PROCEDURE (EXCHANGE$POINTER, DELAY) ADDRESS EXTERNAL; 

DECLARE (EXCHANGE$POINTER, DELAY) ADDRESS; 
END RQWAIT; 

R^ELVL: 

PROCEDURE (LEVEL) EXTERNAL; 

DECLARE LEVEL BYTE; 
END Ri^ELVL; 

DECLARE RQINPX EXCHANGE$DESCRIPTOR PUBLIC; 
DECLARE RgOUTX EXCHANGE$DESCRIPTOR PUBLIC; 

DECLARE RQL6EX INT$£XCHANGE$DESCRIPTOR PUBLIC; 
DECLARE RQL7EX INT$EXCHANGE$DESCRIPTOR PUBLIC; 

INITIALIZATION: 
PROCEDURE; 

OUTPUT (A8253$MODE) = SELECT$2 OR RL$BOTH OR M0DE$3; 
OUTPUT (A8253$CTR2) = LOW(B2400); 
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20 


2 


21 


2 


22 


1 


23 


2 


24 


2 


25 


1 


26 


2 


27 


2 


28 


1 


29 


1 


30 


1 


31 


1 


32 


1 


33 


2 


34 


2 



35 2 OUTPUT(A8253$CTR2) = HIGH (B24kJ0) ; 

36 2 OUTPUT (USART$CONTROL) , 

OUTPUT (USART$CONTROL) , 
OUTPUT (USART$CONTROL) , 
OUTPUT (USART$CONTROL) = 0; 

37 2 OUTPUT (USART$COl\iTROL) = USART$R£S£T; 

38 2 OUTPUT (USART$CONTROL) = ST0P$1 OR CL8 OR RATE$16X; 

39 2 OUTPUT (USART$CONTRCL) = RTS OR ERROR$RESET OR 



40 2 END INITIALIZATION; 



RXE OR DTR OR TXEN ; 



41 1 RD$MIN: 

PROCEDURE PUBLIC; 

42 2 DECLARE (MSGPTR, INTMSG, BUF$ADDRESS) ADDRESS; 

43 2 DECLARE (CHAR,PTR,I) BYTE; 

44 2 DECLARE MSG BASED MSGPTR TH$jyiSG; 

45 2 DECLARE (BUF BASED BUF$ADDRESS) (1) BYTE; 

46 2 ECHO$CHAR: 

PROCEDURE (CHAR) ; 

47 3 DECLARE CHAR BYTE; 

48 3 INTMSG = RQwAIT ( . RQL7EX, ) ; 

49 3 OUTPUT (USART$OUT) = CHAR; 

50 3 END ECHO$ChAR; 

51 2 CALL INITIALIZATION; 



52 


2 


CALL RQ£LVL(6) ; 


53 


2 


CALL RgELVL(7) ; 


54 


2 


DO FOREVER; 


55 


3 


MSGPTR = RQVvAIT(,RQINPX,0) ; 


56 


3 


BUF$ADDRESS = MSG. BUFF£R$ADDRESS - 1; 


57 


3 


PTR = 0; 


58 


3 


CHAR = NOT CR; 


59 


3 


DO WHILE CHAR <> CR; 


60 


4 


INTMSG = RC;WAIT(,RQL6£X,0) ; 


61 


4 


IF (CHAR := INPUT (USART$IN ) AND 7FH) 


62 


4 


DO; 


63 


5 


IF PTR = THEN 


64 


5 


CALL ECHO$CHAR(BELL) ; 
ELSE 


65 


5 


DO; 


66 


6 


CALL ECHO$CHAR(BUF(PTR) ) ; 


67 


6 


PTR = PTR - 1; 


68 


6 


END; 


69 


5 


END; 
ELSE 


70 


4 


DO ; 


71 


5 


IF CHAR = CONTROL$X THEN 


72 


5 


DO; 


73 


6 


CALL ECHO$CHAR('#') ; 


74 


6 


CALL £CHO$CHAR(CR) ; 


75 


6 


CALL ECHO$CHAR(LF) ; 


76 


6 


PTR = 0; 


77 


6 


END; 
ELSE 


78 


5 


DO; 



RUBOUT THEN 
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79 


6 


IF CHAR = CONTROL$R THEM 




80 


6 


DO; 




81 


7 


CALL ECHO$CHAR(CR) ; 




82 


7 


CALL ECHO$CHAR(LF) ; 




83 


7 


DO I = 1 TO PTR; 




84 


8 


CALL ECHO$CHAR(BUF(I) ) ; 




85 


8 


END; 




86 


7 


EMD; 
ELSE 




87 


6 


DO; 




88 


7 


IF PTR < MSG.COUiSiT THEN 




89 


7 


BUF(PTR := PTR+1) = CHAR; 






ELSE 




90 


7 


DO; 




91 


8 


IF CHAR <> CR THEN 




92 


8 


CHAR = BELL; 




93 


8 


END; 




94 


7 


IF CHAR = ESC THEN 




95 


7 


DO; 




96 


8 


CALL ECHO$CHAR( '$ V) ; 




97 


8 


CHAR = CR; 




98 


8 


END; 




99 


7 


CALL £CHO$CHAR(CHAR) ; 




100 


7 


END; 




101 


6 


END; 




102 


5 


END; 




103 


4 


END; 




104 


3 


IF PTR < MSG- COUNT THEN 




105 


3 


BUF(PTR:=PTR+1) = LF; 




106 


3 


MSG. ACTUAL = PTR; 




107 


3 


MSG, STATUS = 0; 




108 


3 


CALL RQSEND(MSG.RESPONSE$EXCHANGE, 


r MSGPTR) ; 


109 


3 


CALL ECHO$CHAR(LF) ; 




110 


3 


END; 




111 


2 


END RD$MIN; 




112 


1 


WR$MIN: 

PROCEDURE PUBLIC; 




113 


2 


DECLARE (MSGPTR,INTMSG,BUF$ADDRESS) 


ADDRESS; 


114 


2 


DECLARE PTR BYTE; 




115 


2 


DECLARE MSG BASED MSGPTR TH$MSG; 




116 


2 


DECLARE (BUF BASED 6UF§ADDRESS) (1) 


BYTE; 


117 


2 


CALL RgELVL(7} ; 




118 


2 


DO FOREVER; 




119 


3 


MSGPTR = RQWAIT(.RQOUTX,0) ; 




120 


3 


BUF$ADDRESS = MSG, BUFFER§ADDRESS - 


- 1; 


121 


3 


DO PTR = 1 TO MSG, COUNT; 




122 


4 


INTMSG = RQWAIT(,RQL7EX,0) ; 




123 


4 


OUTPUT (USART$OUT) = BUF (PTR); 




124 


4 


END; 




125 


3 


MSG, ACTUAL = MSG, COUNT; 




126 


3 


MSG, STATUS = 0; 




127 


3 


CALL RQSEND (MSG, RESPONSE$EXCHANGE 


, MSGPTR) ; 


128 


3 


END; 




129 


2 


END WR$MIN; 




130 


1 


END MINIMAL$TERMINAL$HANDLER; 
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APPENDIX B 

WRMIN ASSEMBLY LANGUAGE LISTING 

LOG OBJ SEQ SOURCE STATEMENT 









1 




NAME 


WRMIN 










2 




EXTRN 


RQELVL,RQOUTX,RQWAIT,RQSEND 








3 




PUBLIC 


WRMIN, RQL7EX 


OGEC 






4 
5 
6 


DATOUT 
WRMIN: 


EQU 
CSEG 


OECH ; 


USART OUTPUT PORT ADR 


0000 


0E07 




7 




MVI 


C,7 




0002 


CDOOOO 


E 


8 
9 


WRO : 


CALL 


RQELVL ; 


ENABLE INTERRUPT LVL 7 


0005 


110000 




10 




LXI 


D,0 




0008 


010000 


E 


11 




LXI 


B,RQ0UTX 




OOOB 


CDOOOO 


E 


12 




CALL 


RQWAIT ; 


WAIT FOR OUTPUT RQST 


OOOE 


E5 




13 




PUSH 


H ; 


PUSH MESSAGE ADDRESS 


OOOF 


110700 




14 




LXI 


D,7 




0012 


19 




15 




DAD 


D 




0013 


4E 




16 




MOV 


CM ; 


GET RESPONSE EXCHANGE 


0014 


23 




17 




INX 


H 




0015 


46 




18 




MOV 


B,M 




0016 


23 




19 




INX 


H 




0017 


C5 




20 




PUSH 


B ; 


PUSH RESPONSE EXCHANGE 


0018 


3600 




21 




MVI 


M,0 ; 


STATUS = 


001A 


23 




22 




INX 


H 




001B 


3600 




23 




MVI 


M,0 




001D 


23 




24 




INX 


H 




001E 


5E 




25 




MOV 


E,M ; 


GET BUFFER ADR^^'lN DE 


001F 


23 




26 




INX 


H 




0020 


56 




27 




MOV 


D,M 




0021 


23 




28 




INX 


H 




0022 


4E 




29 




MOV 


C,M ; 


GET COUNT IN BC 


0023 


23 




30 




INX 


H 




0024 


46 




31 




MOV 


B,M 




0025 


23 




32 




INX 


H 




0026 


71 




33 




MOV 


M,C ; 


ACTUAL = COUNT 


0027 


23 




34 




INX 


H 




0028 


70 




35 
36 


WR1 : 


MOV 


M,B 




0029 


78 




37 




MOV 


A,B 




002A 


B1 




38 




ORA 


C 




002B 


CA4300 


C 


39 




JZ 


WR2 ; 


EXIT LOOP IF COUNT = 


002E 


C5 




40 




PUSH 


B 




002F 


D5 




41 




PUSH 


D 




0030 


1 10000 




42 




LXI 


D,0 




0033 


010000 


D 


43 




LXI 


B,RQL7EX 




0036 


CDOOOO 


E 


44 




CALL 


RQWAIT ; 


WAIT FOR TXRDY INTRPT 


0039 


D1 




45 




POP 


D 




003A 


CI 




46 




POP 


B 




003B 


1 A 




47 




LDAX 


D 




003C 


13 




48 




INX 


D 




003D 


D3EC 




49 




OUT 


DATOUT ; 


TRANSMIT NEXT CHAR 


003F 


OB 




50 




DCX 


B 




0040 


C32900 


C 


51 
52 


WR2: 


JMP 


WR1 
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0043 


C1 




53 




POP 


B 


0044 


D1 




54 




POP 


D 


0045 


CDOOOO 


E 


55 




CALL 


RQSEND 


0048 


C30500 


C 


56 
57 
58 
59 


5 

RQL7EX: 


JMP 
DSEG 


WRO 


OOOF 






60 
61 
62 


1 


DS 
END 


15 



BC = RESPONSE EXCHANGE 

DE = MSG ADDRESS 

SEND MSG TO RESP. EXCH 
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APPENDIX C 

ATOD PL/M LISTING 



1 






ATOD: 
DO; 


2 
3 
4 
5 


1 
1 
1 
1 


= 


$INCLUD 
DECLARE 
DECLARE 
DECLARE 
DECLARE 



TRUE LITERALLY ' OFFH' ; 
FALSE LITERALLY ' OOH* ; 
BOOLEAN LITERALLY 'BYTE'; 
FOREVER LITERALLY 'WHILE 1'; 

$INCLUDE( :F1 :EXCH.ELT) 

6 1 = DECLARE EXCHANGE$DESCRIPTOR LITERALLY 'STRUCTURE ( 

MESSAGE$HEAD ADDRESS, 
MESSAGE$TAIL ADDRESS, 
TASK$HEAD ADDRESS, 
TASK$TAIL ADDRESS, 
EXCHANGE$LINK ADDRESS)'; 

$INCLUDE( :F1 rIED.ELT) 

7 1 = DECLARE INT$EXCHANGE$DESCRIPTOR LITERALLY 'STRUCTURE ( 

MESSAGE$HEAD ADDRESS, 
MESSAGE$TAIL ADDRESS, 
TASK$HEAD ADDRESS, 
TASK$TAIL ADDRESS, 
EXCHANGE$LINK ADDRESS, 
= LINK ADDRESS, 

LENGTH ADDRESS, 
TYPE BYTE) ' ; 

$INCLUDE( :F1 rMSG.ELT) 

8 1 = DECLARE MSG$HDR LITERALLY ' 

LINK ADDRESS, 
LENGTH ADDRESS, 
TYPE BYTE, 

HOME$EXCHANGE ADDRESS, 
RESPONSE$EXCHANGE ADDRESS' ; 

9 1 = DECLARE MSG$DESCRIPTOR LITERALLY 'STRUCTUREC 

MSG$HDR, 

REMAINDER( 1) BYTE) ' ; 

$INCLUDE( :F1 iINTRPT.EXT) 

10 1 = RQENDI: 

PROCEDURE EXTERNAL; 

11 2 = END RQENDI; 

12 1 = RQELVL: 

PROCEDURE (LEVEL) EXTERNAL; 

13 2 = DECLARE LEVEL BYTE; 

14 2 = END RQELVL; 



2-27 



15 


1 


16 


2 


17 


2 


18 


1 


19 


2 


20 


2 



RQDLVL: 

PROCEDURE (LEVEL) EXTERNAL; 
DECLARE LEVEL BYTE; 

END RQDLVL; 

RQSETV: 

PROCEDURE (PROC, LEVEL) EXTERNAL; 
DECLARE PROC ADDRESS; 
DECLARE LEVEL BYTE; 



21 



22 


1 


23 


2 


24 


2 


25 


1 


26 


2 


27 


2 


28 


1 


29 


2 


30 


2 


31 


1 


32 


2 


33 


2 



END RQSETV; 

$INCLUDE( :F1 :SYNCH.EXT) 
RQSEND: 

PROCEDURE (EXCHANGE$ POINTER, MESSAGE$ POINTER) EXTERNAL; 
DECLARE (EXCHANGE$ POINTER, MESS AG E$ POINTER) ADDRESS; 

END RQSEND; 

RQWAIT: 

PROCEDURE ( EXCHANGE$POINTER, DELAY) ADDRESS EXTERNAL; 
DECLARE (EXCHANGE$POINTER, DELAY) ADDRESS; 

END RQWAIT; 

RQACPT: 

PROCEDURE (EXCHANGE$POINTER) ADDRESS EXTERNAL; 
DECLARE EXCHANGE$POINTER ADDRESS; 

END RQACPT; 

RQISND: 

PROCEDURE (IED$PTR) EXTERNAL; 
DECLARE IED$PTR ADDRESS; 

END RQISND; 



34 
35 
36 
37 
38 
39 
40 

41 
42 

43 
44 
45 
46 



/* 

SBC 711 ANALOG TO DIGITAL BOARD 
*/ 

DECLARE ADC$BASE ADDRESS AT (0F700H); 

DECLARE COMMAND$REGISTER BYTE AT ( . ADC$BASE+0 ) ; 

DECLARE STAT]JS$REGISTER BYTE AT ( . ADC$ BASE + ) ; 

DECLARE FIRST$CHANNEL$REGISTER BYTE AT ( * ADC$BASE+ 1 ) ; 

DECLARE LAST$CHANNEL$REGISTER BYTE AT ( . ADC$BASE+2) ; 

DECLARE CLEAR$INTERRUPT$REQUEST BYTE AT ( . ADC$BASE+3 ) ; 

DECLARE ADC$DATA$REGISTER ADDRESS AT ( . ADC$BASE+4 ) ; 

DECLARE GO$BIT LITERALLY M'; 

DECLARE AUTO$INCREMENT$ENABLE LITERALLY '2'; 

DECLARE BUSY LITERALLY '8'; 

DECLARE EOS$INTEl^RUPT$ENABLE LITERALLY MOH'; 

DECLARE EOC$INTERRUPT$ENABLE LITERALLY ♦20H'; 

DECLARE END$OF$SCAN LITERALLY '40H'; 
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48 


1 


49 


1 


50 


1 


51 


1 


52 


1 


53 


1 


54 


1 


55 


1 



47 1 DECLARE END$OF$ CONVERSION LITERALLY '80H*; 

DECLARE DUMMY EXCH ANGE$DESCRIPTOR PUBLIC; 
DECLARE RET$PULSE EXCH ANGE$ DESCRIPTOR PUBLIC; 
DECLARE COMPULSE EXCHANGE$DESCRIPTOR PUBLIC; 
DECLARE TRIGGER EXCH ANGE$DESCRIPTOR PUBLIC; 
DECLARE RET$TRIG EXCH ANGE$DESCRIPTO R PUBLIC; 

DECLARE RQL2EX INT$ EXCH ANGE$ DESCRIPTOR ; 

DECLARE T$PARAM$LOCK EXCH ANGE$DESCRIPTOR EXTERNAL; 

DECLARE B0X$PARAMS(5) STRUCTURE( 
CHANNEL BYTE, 
SET$POINT ADDRESS, 
ERROR ADDRESS, 
OFFSET ADDRESS, 
SAMPLES ADDRESS, 
COUNT ADDRESS, 
ACCUM ADDRESS, 
READING ADDRESS ) EXTERNAL; 

56 1 TICKER$TASK: 

PROCEDURE PUBLIC; 

57 2 DECLARE MSG ADDRESS; 

58 2 DECLARE PULSE$MSG(2) STRUCTURE ( 

MSG$HDR ) ; 

59 2 PULSE$MSG(0) .LENGTH, 

PULSE$MSG( 1) .LENGTH = SI ZE ( PULSE$MSG( ) ) ; 

60 2 PULSE$MSG(0) .TYPE, 

PULSE$MSG( 1) .TYPE = 65; 

61 2 CALL RQSEND( .RET$PULSE, .PULSE$MSG(0) ) ; 

62 2 CALL RQSEND( .RET$PULSE, .PULSE$MSG( 1) ) ; 

63 2 DO FOREVER; 

64 3 MSG = RQWAIT( .DUMMY,5) ; 

65 3 MSG = RQWAIT( .•RET$PULSE,0) ; 

66 3 CALL RQSEND( .GO$PULSE,MSG) ; 

67 3 END; 

68 2 END TICKER$TASK; 

69 1 ADC$TASK: 

PROCEDURE PUBLIC; 

70 2 DECLARE TRIGGER$MSG STRUCTURE ( 

MSG$HDR ) ; 

71 2 DECLARE ( T$MSG , MSG , LOCK$MSG ) ADDRESS; 

72 2 DECLARE I BYTE; 

73 2 DECLARE GAIN LITERALLY '00'; 

74 2 DECLARE N$CHNLS LITERALLY ' 5 ' ; 

75 2 TRIGGER$MSG.LENGTH = SI ZE ( TRIGGER$MSG ) ; 

76 2 TRIGGER$MSG.TYPE = 65; 

77 2 CALL RQSEND( .RET$TRIG, .TRIGGER$MSG) ; 

78 2 CALL RQELVL(2) ; 
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79 2 DO FOREVER; 

80 3 MSG = RQWAIK .GO$PULSE,0) ; 

81 3 CALL RQSEND( <RET$PULSE,MSG) ; 

82 3 LOCK$MSG = RQWAIT( . T$PARAM$LOCK , 0) ; 

83 3 DO I = TO N$CHNLS-1 ; 

84 4 FIRST$CHANNEL$REGISTER = BOX$ P ARAMS ( I ). CHANNEL 

+ R0L(GAIN,6) ; 

85 4 COMMAND$REGISTER = GO$BIT 

OR EOC$INTERRUPT$ENABLE; 

86 4 MSG = RQWAIK .RQL2EX,0) ; 

87 4 COMMAND$REGISTER = 0; 

88 4 BOX$PARAMS( I) *ACCUM = BOX$P ARAMS( I ) . ACCUM 

+ ADC$DATA$REGISTER; 

89 4 END; 

90 3 CALL RQSENDC .T$PARAM$LOCK,LOCK$MSG) ; 

91 3 T$MSG = RQWAIT( <RET$TRIG,0) ; 

92 3 CALL RQSENDC .TRIGGER, T$MSG) ; 

93 3 END; 

94 2 END ADC$TASK; 

95 1 CONTROL$TASK: 

PROCEDURE PUBLIC; 

96 2 DECLARE ( LOCK$MSG , T , MSG ) ADDRESS; 

97 2 DECLARE I BYTE; 

98 2 DECLARE NCHNLS LITERALLY '5'; 

99 2 DECLARE TURN$LAMP$ON 

LITERALLY ' OUTPUT( 0E7H ) = SHL( 1 , 1 ) ' ; 

100 2 DECLARE TURN$LAMP$OFF 

LITERALLY ' OUTPUT( 0E7 H ) = SHL( 1 , 1 ) + 1' ; 

101 2 DECLARE SETUP$8255 LITERALLY ' 0UTPUT( 0E7H) =80H ; 



104 


2 


105 


3 


106 


3 


107 


3 


108 


3 


109 


4 


110 


4 


111 


4 


112 


5 



0UTPUT(0E6H)=0FFH' 



102 2 SETUP$8255; 



DO FOREVER; 

MSG = RQWAIT( .TRIGGER, 0) ; 
CALL RQSENDC cRET$TRIG,MSG) ; 
LOCK$MSG= RQWAIT( . T$ PAR AM$LOCK , ) ; 
DO I = TO NCHNLS-1 ; 

BOX$PARAMS( I) .COUNT = BOX$P ARAMS ( I ). COUNT + 1; 
IF BOX$PARAMS( I) .COUNT 

= BOX$PARAMS( I) .SAMPLES THEN 
DO; 
T, 

BOX$PARAMS( I) .READING 
= (BOX$PARAMS( I) .ACCUM 

/BOX$PARAMS( I) .SAMPLES) / 38 
+ BOX$PARAMS( I) .OFFSET; 
113 5 IF T <= BOX$PARAMS( I) .SET$POINT 

- BOX$PARAMS( I) .ERROR THEN 
1 14 5 TURN$LAMP$ON; 

ELSE 
115 5 IF T >= BOX$PARAMS( I) .SET$POINT 

+ BOX$PARAMS(I) .ERROR THEN 
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116 


5 


TURN$LAMP$OFF; 
BOX$PARAMS( I) .ACCUM, 
BOX$PARAMS( I) .COUNT = 0; 


118 


5 


END; 


119 


4 


END; 


120 


3 


CALL RQSEND( . T$ P AR AM$LOCK , LOCK$MSG ) ; 


121 


3 


END; 



122 



123 



END CONTROL$TASK; 
END ATOD; 
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I. INTRODUCTION 

In March of 1978, Intel announced the availability of a 
resident FORTRAN compiler for the Intellec® Micro- 
computer Development System. In November of 1978, 
Intel announced the availability of a run-time package 
to support the execution of FORTRAN-80 compiled 
programs in the RMX/80^'^ environment. With this sup- 
port package, user's of Intel's complete line of iSBC^^ 
Single Board Computer products can benefit from the 
full set of I/O and math capabilities provided by the 
FORTRAN-80 language. 

This application note is intended to familiarize the 
reader with the features, benefits and usage of the 
FORTRAN-80 package and RMX/80™ Executive. The 
reader who is unfamiliar with any of these topics is 
urged to refer to the related Intel publications listed in 
the front-piece. 

Following the overview, two application examples will 
be studied. In the first example, FORTRAN code is used 
in a "stand-alone" environment; i.e., without operating 
system support. The second example is a multitasking 
system managed by the RMX/80 Executive which sup- 
ports standard I/O interfaces to the RMX/80 Terminal 
Handler and Disk File System. 



II. OVERVIEW 

Intel's FORTRAN-80 compiler is an implementation of 
the standard FORTRAN known as ANS FORTRAN 77 
approved by the American National Standards Institute 
(ANSI) in April, 1978. The implementation is of the 
FORTRAN 77 subset, plus most of the full I/O capabil- 
ity and Intel defined extensions. For a fuller description 



of the implementation, consult the FORTRAN-80 Pro- 
gramming Manual. 

FORTRAN-80 is a high level applications program- 
ming language with flexible I/O handling and floating- 
point math instructions. With the FORTRAN-80 lan- 
guage, the programmer can easily implement sophisti- 
cated applications involving scientific calculations, 
process and instrument control, test and measurement, 
and a host of other applications requiring the power 
and flexibility the FORTRAN-80 language provides. 

With the addition of the iSBC 801 FORTRAN-80 
RUN-TIME PACKAGE for RMX/80 SYSTEMS, the 
user who wishes to implement his application using 
Intel's Single Board Computers and the RMX/80 Real- 
Time Multitasking Executive can take full advantage of 
the FORTRAN-80 I/O and math capabilities. The pack- 
age allows the user to accelerate the run-time execution 
of FORTRAN-80 coded mathematical formulae through 
special interfaces to the optional iSBC 310^^ High 
Speed Mathematics Unit. All disk and terminal I/O is 
interfaced directly to the RMX/80 Disk File System and 
either the full or the minimal Terminal Handler. The 
libraries that comprise the iSBC package are construc- 
ted in a modular fashion, allowing the user to configure 
systems with as much or as little of the support libraries 
as needed for a given application. 

In order to effectively utilize the hardware and software 
products now available, it is important to design the ap- 
plication system from the top down. This implies that 
we need to think of an application in very general terms 
and then successively introduce more detail until we 
have program code as our final step. At each stage of 
the definition, we have to make decisions about the us- 
age and configuration of various products. 
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The decision-making process that concerns itself with 
software can be shown as a tree (Figure 1). The first 
decision that must be made is whether or not the 
RMX/80 Real-Time Multitasking Executive should be 
utilized. In general, this package will prove extremely 
useful if the application to be designed must respond to 
multiple asynchronous events, or contains multiple, 
semi-independent processes that could be executed in 
parallel, or has need of standard vendor supplied device 
drivers. If the application is very small and simple, 
handles few or no interrupts, has no need for parallel 
execution of multiple processes, and the designer is 
willing to supply his own I/O device drivers, the pro- 
gram may be able to execute without the support of an 
operating system. 

Whether the RMX/80 package is used or not, the system 
designer must now choose in which language or 
languages the programs should be coded. Each of the 
three languages shown is optimized for different pur- 
poses. The PL/M-80 language is well suited for systems 
programming. The ASM-80 language is best suited for 
applications requiring direct control of the computer 
(e.g., the registers and memory). The FORTRAN-80 
language is highly desirable for those applications 
requiring mathematical calculations and formatted 



I/O. In many cases, the optimal solution will use a mix 
of two or even all three of these languages. 

III. USING FORTRAN-80 
I/O Capabilities 

After the decision has been made to use the FORTRAN- 
80 language for an application, various types of I/O 
support are available to the user (see Figure 2). If the 
program code is to run without any support from an 
operating system, the user must supply drivers for any 
devices he wishes to include in his system. 

When designing an RMX/80 system, the iSBC 801 pack- 
age supplies the standard interface to the disk and 
terminal while the user may support additional devices 
in the same manner as the "stand alone" program 
would. The following sections expand on the topic of 
FORTRAN-80 I/O support. 

Portl/O 

The simplest and most direct method of performing I/O 
in the FORTRAN-80 language uses two pre-defined sub- 
routines, INPUT and OUTPUT. The example below il- 
lustrates the use of these subroutines to input bytes from 
and output bytes to any of the 8080A/8085A I/O ports. 



NON-RMX/80TM 
FORTRAN-80 




PORT 
I/O 



INTERNAL 

BUFFER 

FORMATTING 



USER HIGH- 
LEVEL DRIVERS 



RMX/80TM 
FORTRAN-80 




RMX-80TM 
DISK FILE 
SYSTEM 



RMX/80TM 
TERMINAL 
HANDLER 



NON 

STANDARD 

DEVICES 



INTERNAL 
BUFFERS 



USER HIGH- 
LEVEL DRIVERS 



Figure 2. The I/O Support Decision 
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INTEGER* 1 IVAL 

C 

C - PROGRAM THE 8255 PARALLEL I/O CHIP 

C-PORT# = EB; VALUE = 94 

C 

CALL OUTPUT (#OEBH, # 94H) 



C -- CALL DEVICE DRIVER TO OUTPUT BUFFER 
C 

CALL BUFOUT (BUFFER) 



C - INPUT 8 BITS FROM PORT A INTO IVAL 
C - PORT # = E8; VALUE INPUT TO IVAL 
C 

CALL INPUT (#0E8H,IVAL) 



Port I/O is extremely useful in many applications. How- 
ever, this method requires the programmer to directly 
handle each and every byte. Also, it does not utilize the 
power of the FORTRAN-80 formatting routines. 

Internal Buffer Formatting 

One method of overcoming the shortcomings of Port 
I/O is to use character strings as "virtual devices." This 
is accomplished by specifying a character string as the 
unit number in a READ or WRITE statement. External 
routines can be used to fill the character strings with 
input for the READ statement and to output buffers that 
have been formatted by the WRITE statement. The ex- 
ample below shows the use of this method. 

SUBROUTINE EXAMPL 
CHARACTER* 80 BUFFER 



User Provided High-Level Drivers 

If an application requires only simple input (READ) and 
output (WRITE) capabilities, the previous method 
would probably be sufficient. If, however, the device(s) 
in thesystem are more complex, it may be necessary to 
perform other I/O operations. One way of doing this 
would be to write subroutines for each operation. A 
much nicer solution is to use the FORTRAN-8() I/O in- 
structions (OPEN, CLOSE, READ, WRITE, PRINT, 
BACKSPACE, REWIND, and ENDFILE) to interface 
to user-written routines which implement these instruc- 
tions for the special device. 

This is possible because, for each open file in the system, 
the FORTRAN-80 I/O system keeps a table connecting 
the unit number with the addresses of the routines that 
handle all operations on that unit. The I/O system 
allows the user to substitute his own device drivers into 
this table. To do this, the system designer codes a 
routine and labels it FQOLVL. This routine is then 
made known to the I/O system (i.e., declared PUBLIC). 
Whenever a file is first accessed (i.e., OPENED), the I/O 
system calls FQOLVL with a set of parameters, one of 
which is the file name referenced in the OPEN state- 
ment. The designer, in his code for FQOLVL, scans the 
file name to decide if this is one of the files for which he 
wishes to supply drivers. If so, he passes back a table of 
the addresses of the routines that will take care of the 
eight primitive file I/O capabilities (refer to the example 
following this paragraph and to the FORTRAN-80 
Compiler Operators Manual). 



C - CALL DEVICE DRIVER TO GET BUFFER OF 

C- CHARACTERS 

C 

CALL BUFIN (BUFFER) 
C 

C - NOW READ FROM BUFFER INTO VARIABLES 
C - UNDER FORMAT CONTROL 
C 

READ (BUFFER, 100) X, Y, Z 
100 FORMAT (F10.3, F12.4, FI3.5) 

• 

• PROCESS DATA STORED IN VARIABLES 

• X, Y, Z 



C - WRITE RESULTS TO BUFFER 
C 

WRITE (BUFFER, 200) A, B, C, D 
200 FORMAT (4F 12. 3) 
C 



FQ0LVL: PROCEDURE (file$ptr,bufSptr) BYTE PUBLIC; 

/* table of entry point addresses for driver routines ' 

DECLARE table (8) ADDRESS DATA ( 



.open$hdlr, 


/* 


address 


of 


OPEN routine */ 


.closeShdlr, 


/* 


address 


of 


CLOSE routine */ 


.read$hdlr. 


/* 


address 


of 


READ routine */ 


.write$hdlr, 


/* 


address 


ot 


WRITE routine */ 


.back$hdlr. 


/* 


address 


of 


BACKSPACE routine */ 


.mv2rec$hdlr. 


/* 


address 


of 


MV2REC routine */ 


.rewind$hdlr. 


/* 


address 


of 


REWIND routine */ 


.make$eof$hdlr 


/* 


address 


of 


END OF FILE routihe */ 



); 

DECLARE (returned$status, index) BYTE; 
DECLARE (fileSptr,buf$ptr) ADDRESS; 
DECLARE buf BASED buf$ptr (1) BYTE; 
DECLARE fileSname BASED file$ptr (1) BYTE; 
DECLARE analog$in (*) BYTE DATA( ' :AI : ' ) ; 

/* set flag initially -FFH */ 

returned$status=0FFH; 

/* if any character of fileSname does not compare set flag=0 */ 

DO index=0 TO 3; 

IF f ilename(index) <> analog$in(index) THEN 

returned$status=0; 
END; 

/* if flag=FFH pass back the addresses of the drivers */ 

IF returned$status=0FFH THEN 

CALL move (size (table) , .table, buf $ptr) ; 
RETURN returnedSstatus; 
END; /* of FQ0LVL •/ 



2-37 



RMX/80TW Support 

When using the RMX/80 Executive, the iSBC 801 
FORTRAN-80 RUN-TIME PACKAGE for RMX/80 
SYSTEMS can be used to provide a direct interface to 
standard RMX/80 high level drivers, the Disk File 
System and the Terminal Handler. With the RMX/80 
Executive, users can code multiple, concurrently 
executing programs that perform formatted I/O to disk 
files and the console, as shown in the following 
example: 



C - OPEN disk file 

C 

OPEN (8,FILE = 
'SEQUENTIAL') 

C 

C - perform tests 

C 



:DO:TSTDTA.FIL',ACCESS 



can make the decision to use a software package to 
implement the floating point support or to accelerate the 
execution of these operations (by as much as a factor of 
five or six) by installing an iSBC 310 High-Speed Mathe- 
matics Unit and linking in special FORTRAN-310 
drivers. In either case, due to the adherence to the 
standard, the results of all calculations will be identical. 
In addition, the libraries have been designed to allow the 
switch to be made from software routines to a faster hard- 
ware solution with no code changes. 

Above and beyond the basic mathematical operators in 
FORTRAN-80, a large number of intrinsic functions 
are available. These functions provide services like type 
conversion, remaindering, and logarithmic and trigo- 
nometric calculation. Since the calculations involved 
in performing these high-level functions require the 
mathematical operators, they too can be accelerated by 
the inclusion of the iSBC 310 board and its associated 
drivers. 



C ~ WRITE results to file for archival storage 
C 

WRITE(8, 1 00) (RESULT (I),I = 1 , 1 0) 
100FORMAT(10F12.3) 
C 

C ~ PRINT completion message on console 
C 

PRINT 200 
200 FORMAT (TESTS COMPLETE') 



If it is necessary for a FORTRAN program in the 
RMX/80 system to perform I/O to a device not handled 
by one of the high level drivers, any of the methods pre- 
viously described can be utilized to augment the I/O 
system. 

FORTRAN-80 Math Capabilities 

The FORTRAN-80 language supports four data types 
labelled INTEGER, REAL, LOGICAL, and CHARAC- 
TER. Also supported are various operators which can 
manipulate objects of various types. Both INTEGER 
(fixed point) and REAL (floating-point) objects can be 
manipulated by the add ( + ), subtract ( - ), multiply (*), 
divide(/), and exponentiation (* *) operators. In addition, 
Integers can be operated on by the Boolean operators 
(e.g., .AND., .OR.). In this case, the operations are per- 
formed bit-wise on the operands. 

All floating-point arithmetic operations are performed 
with algorithms that adhere to the Intel Floating-Point 
Standard' which allows for seven decimal digits of pre- 
cision. Whenever math operations are used, the user 



Error Handling 

The math processing system also provides flexible error 
handling. The user can choose to use either an Intel- 
supplied error handler or one of his own design. The 
capability also exists to change the active error handler 
dynamically in cases where different routines require 
different handlers. The default error handlers are named 
FQFERH. One exists in each of the arithmetic libraries 
(Figure 3). This error handler will attempt to recover 
from an error by taking the most reasonable action (e. g., 
underflow error returns result = 0). If code is being run 
"stand-alone" or under the RMX/80 executive the 
handlers in the math libraries should be used or the user 
should supply his own. Appendix B of the ISIS-II FOR- 
TRAN-80 Compiler Operator's Manual contains all of 
the information necessary to implement a custom error 
handler or to use the default routines. 



FPSOFT.LIB - Software package for "stand-alone" 

and ISIS-II systems 
FPHARD.LIB - iSBC 310 drivers for same 
* FPSFTX.LIB - Software package for RMX/80 systems 
♦FPHRDX.LIB - iSBC 310 drivers for iSBC 80/20, 

80/20-4 and 80/30 boards 
♦FPHXIO.LIB - iSBC 310 drivers for iSBC 80/10 and 
80/ lOA boards 
FPEF.LIB - Library of routines implementing 
intrinsic functions 

* Available in iSBC 801 FORTRAN-80 RUN-TIME 
PACKAGE for RMX/80 Systems. 

Figure 3. Available Math Libraries 



I Palmer, John F., "The Intel Standard for Floating-Point Arithmetic," Proceedings of the 
First International Computer Software and Applications Conference (Chicago: IEEE Com- 
puter Society), November, 1977,pp 107-112. 
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IV. APPLICATION EXAMPLE 

An Automated Test Stand 

This example shows the steps taken to design and imple- 
ment an automated test stand. The hardware system 
must interface to a test fixture upon which test items can 
be mounted. Operator inputs and test outputs involve a 
300-baud hard copy terminal. The software to be devel- 
oped must allow an operator to invoke a variety of tests 
from the console and to receive some printed perfor- 
mance record for the object under test. In addition, the 
software must allow for tests to be added and deleted 
often, and each test must be allowed to obtain any 
number of parameters from the command line tail. 

After examining the problem definition and the decision 
making diagram presented earlier, it was decided that 
this application could be implemented with a simple 
sequential program. 

Since formatted I/O and mathematical calculations 
are involved, the FORTRAN-80 language is well suited 
to be the main programming language. Also, some 
ASM-80 routines will come in handy for communicating 
with the console. 

An analysis of the I/O to be performed breaks down into 
two distinct types. Various inputs to and outputs from the 
text fixture will be 8-bit parallel transfers. These will 
likely go through the 8255A ports on the Single Board 
Computer. Port I/O will be used to handle this function. 
Interface with the operator requires READ'S AND 
WRITE's to the console device. The simplest way of per- 
forming this function is to use character strings as the 
target of READ and WRITE operations and coding small 
ASM-80 routines to transfer these buffers from/to the 
console. 

A diagram of the test stand is shown in Figure 4. The 
computer hardware necessary to solve this application 
includes a. Single Board Computer (the iSBC 80/20 
board), a PROM memory module and an analog I/O 
board. Digital I/O with the test fixture is handled by the 
8255A ports on the Single Board Computer. The analog 
inputs on the test fixture come from the two D/A conver- 
ter channels on ihe iSBC 732 board. 

The software solution utilizes a very rudimentary com- 
mand line interpreter. The mainline routine gets a line 
of input and finds the first non-blank character. If this 
character is an alphabetic character, it is used in a 
computed GOTO statement to transfer control to one 
of a possible 26 entry points. Tests may be added by 
choosing a keyletter and inserting a label in the GOTO 
statement to transfer control to the new test routine. The 
command input line and the index in the line are stored 
in a common block so that any test routine can continue 
scanning the line for parameters or can reset the index 
and find out what keyletter caused its invocation. The 
flow of the software is illustrated in Figure 5. 

For the purpose of explanation, routines are shown to 
implement a "calculator mode" which allows the opera- 



tor to perform arithmetic from the console, and a logic 
transition tester which determines whether the object on 
the test fixture changes state at the proper voltages. 




COMPUTER 
SYSTEM 



\Z 






TEST 
FIXTURE 



Figure 4. Test Stand Diagram 



Code Description 

The following sections describe the program code for 
this application example. Fold-out code listings are con- 
tained in Appendix A. The circled reference letters in 
the text refer to the corresponding letters in the listings. 



The DRIVRS Module 

The module DRIVRS contains three primary routines. 
START (S) is located at so that it is executed upon 
power up. This routine is responsible for programming 
the on-board hardware (8255A, 8251, 8253), setting up 
the system stack, and calling the FORTRAN routine 
labeled MAINLN. 

The input routine BUFIN (B) is called from 
FORTRAN routines with a character string as an argu- 
ment. Note that passing a string argument from FOR- 
TRAN results in the address and length of the string 
being sent as parameters. The string is filled with char- 
acters input from the console until a carriage return is 
encountered. A simple line-editing scheme is imple- 
mented allowing character deletion (RUBOUT), line de- 
letion (CONTROL-X), and echoing of the current buffer 
contents (CONTROL-R). Attempted entry of characters 
beyond the end of the string and RUBOUTS past the be- 
ginning cause the audible bell to sound. 
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The output routine, BUFOUT (C) , also takes a char- 
acter string as an argument. The entire contents of the 
string are sent to the console unless a carriage return is 
encountered in the string. If a carriage return is the ter- 
minator, a line feed is output as well. If a CONTROL-S 
is entered at the console while output is in progress, 
output is suspended until a CONTROL-Q is typed. 

f START J 




GET 
COMMAND 



GET FIRST 
NON-BLANK 
CHARACTER 




GOTO 
PROPER 
ROUTINE 





Figure 5. Flow Diagram 



The MAINLN Module 

The module MAINLN (B) contains the mainline rou- 
tine that implements the command line interpreter. The 
statement IMPLICIT LOGICAL A-Z will cause most 
usages of undeclared variables to be reported as illegal 
mixed mode; the intent in writing these programs was 
to declare all variables, which is generally considered 



good programming practice, even though Fortran 
makes default assumptions about undeclared variables. 

The default handler is to be used for any errors that 
may occur while performing mathematical calculations. 
Also, the routines that perform the calculations must be 
initialized. Both of these operations are performed by 
the call to FQFSET (e) . The call takes two arguments. 
The first argument is a two byte field specifying which 
error handler is to be used. If the low order bit of the 
high order byte is a one (e.g., 100 hexadecimal), the 
math routines will call a u.ser error handler whose 
address is given as the second parameter. If the low 
order bit is zero (as is the case in this example), the 
routines will use the default handler and ignore the 
second argument. 

A banner is output to the console by the sequence at 
(F) where a formatted WRITE is performed on an 
internal buffer (IMAGE) and then the external driver 
BUFOUT is called to output the buffer to the console. 
The variable GARRET is used to insert a carriage 
return into the string to be output. In order to allow in- 
dividual characters in the character string to be accessed, 
the EQUIVALENCE statement is used to cause 
LINBUF and IMAGE to occupy the same memory 
space. The variable INDEX (G) is used to scan 
through the input buffer. 

A call to BUFIN (ly fetches the command line from 
the console. DBLANK is called to position INDEX 
to the first non-blank character. This character is con- 
verted to its integer representation, normalized to 1 and 
checked to see if it is a valid alphabetic character Q) . 
If the keyletter is valid, the computed GOTO 
causes execution to branch to the correct point in a 
jump table . Note that A (add,) S (subtract), M 
(multiply), and D (divide) all branch to a single routine 
MATH, T (transition test) branches to a routine called 
TRANST and all other keyletters are trapped into line 
100. Any and all I/O errors cause the ERROR routine to 
be called. 

The DBLANK Module 

The DBLANK routine @ de-blanks the input line. If 
a carriage return is encountered, the operator is 
prompted for more input. 

The ERROR Module 

The ERROR routine (n) prints out an error message, 
with the error number, to the console. 

The MATH Module 

In many of the tests, the human operator must supply 
numeric parameters. A calculator mode is supplied for 
the simple calculations that might be needed here. This 
mode is implemented through the MATH routine (O) . 
Since any one of four keyletters could have caused this 
routine to be invoked, MATH rescans the command line 
to obtain the keyletter \P) . Following this, two oper- 
ands are read in by calls to CONVRT (0) and the 
operation requested is performed on them. 
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The CONVRT Module 

Subroutine CONVRT (R) is called from other routines 
to extract floating-point operands from the input line 
buffer. Characters are transferred into a temporary 
buffer (s) until either a carriage return or a comma is 
encountered. The temporary buffer is then read under 
format control to obtain the returned value (t) . 

The TRANST Module 

The item to be tested is composed of combinatorial 
logic as shown in Figure 6, The transition test sets all 
inputs except one to a constant value. By varying the 
voltage at the remaining input, the transitions at the 
output can be checked. This test must be run while the 
+ 5V power to the fixture is varied through a range of 
values. This testing is performed by the TRANST 
routine. 



Power is supplied to the test fixture through one of the 
two D/A channels on the iSBC^M 732. Three of the input 
parameters specify the starting and stopping voltage 
values for Vcc and the increment to be added each step. 
The fourth parameter is the tolerance to be used to 
decide if the test passes or fails at each step. Once the 
test is running, the output voltage at (T) is measured 
for inputs at (T) of and 5V. The voltage input is then 
incremented from OV (using D/A channel 1) until a 
transition is sensed in the output voltage at (2) . At 
this point, the input voltage at (7) is checked to see if 
it is within tolerance. The same process is then repeated 
with the voltage at (Y) going from 4- 5V downward. 
After the test is complete, a formatted report is 
generated containing the ambient temperature 
(measured through a temperature sensor) and the per- 
formance record for the item under test. 
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Figure 6. Transition Test 
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Figure 7. Sample Output 
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An external routine @ , ADCIN, is called to input 
samples into the variable given as the first parameter 
from the channel given as the second parameter. The 
counts from the temperature sensor exhibit a logarith- 
mic curve, so the input is linearized using the equation 
shown. The routine DACOUT @ takes the first para- 
meter and outputs it to the channel specified by the 
second parameter. If no transition occurs when the test 
input is run through its entire range, the item is assumed 
non-functional, a message is output, and control is re- 
turned to the console yJV) . 

The ADCIN Module 

Subroutine ADGIN (x) fetches samples from the A/D 
converter on the iSBC 732 board. The channel number 
is an input parameter and the data is the returned value. 
Of special note in this routine is the use of the FORTRAN 
common block to control a memory-mapped device. 
The master CPU communicates with the iSBC 732 by 
way of memory read and write commands instead of 
I/O commands. The primary reason for this is the fact 
that the 8080A IN and OUT instructions operate on 
only 8 bits at a time whereas SHLD and LHLD instruc- 
tions can manipulate 16 bit operands. This is 
convenient when working with 12-bit inputs from the 
A/D and 12 bit outputs to the D/A. In the code, a 
common block is created which has the same makeup as 
the memory mapped registers on the iSBC 732 board. 
The common block will be origined at the address of the 
iSBC 732 by the ISIS-II LOCATE program. 



satisfy this reference, MAINLN.OBJ is linked in from 
FRTMOD.LIB and its EXTERNAL references cause the 
inclusion of other modules. 

The LOCATE command shown in Figure 9 is used to 
assign absolute memory locations to the code in the 
LINKED modules. The common block labelled ADC is 
explicitly assigned to FFFOH so that it will correctly 
overlay the memory-mapped space of the iSBC 732 
board. The ORDER statement is used to tell the locator 
in what order the various segments should be placed in 
memory. 



LI.MK :FJ :DRIVRS.OBJ, & 

:F1: FRTMOD.LIB, & 

:F0:F8 0RUN.LIB, S< 

:F0:F80NIO.LIB, & 

:F0:F80ISS.LIB, & 

:F0:FPEF.LIB, S 

:F0: FPSOFT.LIB, & 

:F0:PLM8 0.LIB S, 
TO :FI:TSTND.LK0 PRINT (: Fl : TSTND. LNK) MAP 



Figure 8. LINK Command for Test Stand Example 



The DACOUT Module 

Subroutine DACOUT ® makes use of the same com- 
mon block to output given values to a specified D/A 
channel. 

LINK and LOCATE 

The ISIS-II LINK command needed to pull together the 
individual pieces of this example is shown in Figure 8. 
After compilation, the object modules of all of the pre- 
viously described routines are placed in the library 
FRTMOD.LIB by the ISIS-II Library Manager™. The 
LINK statement starts with the module DRIVRS.OBJ, 
which has one EXTERNAL reference, MAINLN. To 



V. USING THE FORTRAN-80 RUN-TIME PACKAGE 
FOR RMX/80™ SYSTEMS 

The iSBC 801 package provides I/O interface and math 
routines for users who are coding RMX/80 applications 
in the FORTRAN-80 language. In the following sec- 
tions, an overview of the RMX/80 system will be 
presented along with a discussion of the use of the iSBC 
801 package. This overview is not intended to be ex- 
haustive. If the reader is unfamiliar with the RMX/80 
package, he should gain from this section enough un- 
derstanding to comprehend the concepts in the example 
presented. If the reader is planning on implementing an 
RMX/80 system, the RMX/80 references in the front- 
piece should be studied carefully. 



LOCATE :F1: TSTND. LK0 PRINT (: Fl : TSTND. LOG) I^AP LINES SYMBOLS PUBLICS 
ORDER (CODE DATA /LINE/ /ADC/) /ADC/ (0FFF0H ) STACKSIZE(0) CODE(0) 

Figure 9. Locate Command for Test Stand Example 
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Overview of the RMX/80tm Executive 

A large number of microcomputer applications require 
the ability to respond to events in real-time. The 
RMX/80 Executive provides the system software around 
which you can build a real-time multitasking applica- 
tion using Intel iSBC 80^^ Single Board Computers. In 
addition, the RMX/80 package provides the application 
designer with various high-level drivers (such as a 
terminal handler and a disk file system) which make it 
easier to develop sophisticated applications software. 



The RMX/SOTf^ Model 

At this time, it is appropriate to discuss the RMX/80 
model, or in other words, the general concepts upon 
which the RMX/80 Executive is built. Real-time 
systems, such as the RMX/80 system, provide the cap- 
ability to control and respond to events occurring asyn- 
chronously in the physical world. To handle these 
events, the application is broken up into smaller semi- 
independent pieces, and each of these pieces is brought 
into action to handle the event for which it is intended. 
Each of these independent program units is a task. The 
RMX/80 Executive manages the execution of these tasks 
in accordance with a user-designated priority scheme to 
insure that the highest-priority task in the system has 
control of the CPU. It is also necessary, in a system such 
as this, for these semi-independent program units (tasks) 
to communicate with each other. This communication 
may be for the purpose of synchronization, data 
passing, mutual exclusion or any other use that may 
arise. To facilitate inter-task communication, the 
RMX/80 model incorporates the notion of messages and 
exchanges. A message is a data structure that can con- 
tain an arbitrary amount of information to be commun- 
icated from one task to another. An exchange is a "mail 
box" where tasks may send messages to be picked up by 
other tasks. The primary operations (primitives) that 
accomplish message transfers in the RMX/80 system are 
RQSEND* and RQWAIT*. Figure 10 diagramatically 
shows the interaction of tasks, messages, and exchanges 
and introduces the symbolism used to represent these 
RMX/80 concepts in the system design. 



Tasks 

Typically, a task will execute a section of code that per- 
forms some initialization and then enters an infinite 
loop performing some processing over and over again 
as shown in Figure 1 1 . 

Each task in the system has a priority associated with it. 
The RMX/80 Executive uses this priority scheme to de- 
termine which ready task to run. The assignment of 
priorities to individual tasks is up to the system design- 
er, giving him the capability to tune his system by 
assuring timely execution of important functions. 



EXCHANGE 
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TASK SENDING MESSAGE 



TASK RECEIVING MESSAGE 
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Figure 10. Task, Message, Exchange interaction 

SUBROUTINE TASK] 

- DECLARATION OF VARIABLES HERE 

- INITIALIZE VARIABLES AND I/O PORTS 

CALL OUTPUT (#0E8H,0) 
FLAG = 1 
INDEX = 1 
COUNT = 
SUM = 

- ENTER INFINITE LOOP 
CALL INPUT(#0E9H,IVAL) 



GOTO I 
END 

Figure 1 1 . Tasl( Loop 



*In order to cliffi-rentiati- KMX/80 procrdurt-s and data stri 
of system objects are always preceded by RQ- 



c 
c- 
c 
I 
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Each RMX/80 task also has its own stack, and there is 
no system stack. Whenever a task must give up the pro- 
cessor (e.g., must wait for the occurance of an interrupt) 
all of the information necessary to reawaken it at some 
future time without affecting the results of it's proces- 
sing is stored on its stack. 



Exchanges 

An exchange in the RVIX/80 system is a data structure 
that contains pointers to lists of tasks and messages. 
Whenever a message is sent to an exchange where there 
are no tasks v/aiting, it is added to the list of messages at 
that exchange until a task accepts it. Similarly, if a task 
waits at an exchange for a message and there is no mes- 
sage in the list, the task is added to the list of tasks wait- 
ing at that exchange. In both cases, the tasks and mes- 
sages are serviced on a first come, first served basis. Fig- 
ure 12 shows the possible states an exchange may be in 
at a given time. 



system to be utilized are contained in this section of 
code. Configuration modules can be coded in either 
PL/M or assembly language (for which there are macros 
included with the RMX/80 product.) 



Memory Usage 

In systems using disk, it is necessary to ensure that cer- 
tain buffers used by the disk controller for Direct Mem- 
ory Access (DMA) are located in memory that is acces- 
sible to the disk controller. The buffers needed are allo- 
cated in a separate module called the controller addres- 
sable memory module. In the case of the iSBC 80/10, 
80/lOA, 80/20, and 80/20-4 boards, this module should 
be LOCATED before being included in the LINK state- 
ment to make sure that it does not contain any RAM on 
the CPU board itself (and, therefore, not controller- 
addressable). This restriction does not apply to iSBC 
80/30 systems, since the iSBC 80/30 board has a dual 
port bus allowing system access to on-board RAM. 
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Figure 12. Exchange Lists 



Messages 

A message in the RMX/80 system is a contiguous section 
of memory of an arbitrary length. Information can be 
stored in the message prior to it being sent to an 
exchange where it will be accepted by another task. 

Configuration 

The configuration module contains various tables and 
PUBLIC variables that are accessed by the system at 
start-up time. All of the necessary information on the 
tasks and exchanges to be created and the disk file 



VL APPLICATION EXAMPLE 

A Sewage Treatment Plant Control System 

In the early 1900's, the most popular type of sewage 
treatment system was known as a Sequencing Batch 
Reactor. It provided excellent effluent quality, but as 
populations grew, the amount of control necessary to 
operate the plant became too great for human opera- 
tors, and a new type of treatment system came into use. 
This new system did not require such accurate control, 
but it also did not perform as well. With the passage of 
stricter and stricter water quality laws, and with the 
advent of low-cost, high powered microcomputer con- 
trol systems, a serious look is being taken once again at 
Sequencing Batch Reactors. 

A diagram of the treatment system and its sensors and 
actuators is shown in Figure 13. The system usually 
consists of three tanks, with each tank having individual 
influent and effluent valves, mixers and aeration equip- 
ment. 

At any given time, all influent is being routed to one 
tank. When this tank is filled, the influent is routed to 
one of the other two. The full tank is agitated and 
aerated until the bacteria in the tank digest the sewage 
to within given limits. At this time, the mixer and aer- 
ator are turned off and the contents settle. After a time, 
the supernatant fluid is drawn off lea\'ing the layer of 
concentrated bacteria to digest the next batch. 

The computer control system necessary for controlling 
these reactors is shown in Figure 14. The system is res- 
ponsible for monitoring the various sensors and contact 
closures, maintaining archives of system status, logging 
reports upon command, activating operator alarms, 
and performing on-line control of the batch cycle. 
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Figure 13. Sewage Treatment System and Sensors 



Software 

An analysis of the functions that need to be performed 
by the software for this control system leads to a 
decision to use the RMX/80 Executive. Timely response 
to multiple asynchronous events is the main thrust of 
this application. A breakdown of the individual func- 
tions in the system would be: 

• data collection — gathers inputs from the sensors and 
contact closures and stores them where other routines 
can access them. Also, converts data from analog 
counts to engineering units. 

• on-line control — based on current sensor inputs 
determines whether aeration, agitation, discharge 
and fill should be on or off. 

• alarm scanning — compares current status values 
with setpoints and sets operator alarms if conditions 
are out of tolerance when effluent is on. 

• data logging — once every five minutes logs current 
system status into a disk file record. 

• real-time clock — maintains day, month, year, and 
time of day. 

• operator console handler — monitors operator con- 
sole to detect operator commands for time and set- 
point changes, report generation, alarm clearing, etc. 

• report generation — upon operator command, for- 
mats either the file corresponding to yesterday's oper- 
ation or today's operation to the current moment. 

Each of these functions must be studied independently 



before the decision on which language to use for each is 
made. The functions concerned with data collection, 
on-line control, and alarm scanning will be concerned 
with mathematical calculations. The functions concern- 
ed with data logging and report generation will have 
need of formatted disk and console I/O. These routines 
will thus be coded in the FORTRAN-80 language. 

As was mentioned earlier, the PL/M-80 language is a 
systems programming language. This means that it is 
optimized to deal with the concepts embodied in a high- 
level system such as the RMX/80 system. The program 
code that implements the real-time clock and operator 
console handler will be written in the PL/M-80 
language. In addition, various PL/M-80 support routines 
will be written to be called on by one or more of the 
FORTRAN-80 routines. The purpose of these routines 
will be explained as they come up in the code descrip- 
tions following. 
Hardware 

The hardware used to implement this control system 
must perform the following functions: 

• inputting analog samples from the various sensors 

• outputting analog values to the pneumatic positioners 

• inputting digital values from the contact closures and 
operator console 

• outputting digital values to the operator console and 
alarm panel 

• storing and retrieving data from diskette files 
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Figure 14. Computer Control System 



The hardware configuration chosen includes an iSBC 
80/30 Single Board Computer, an iSBC 732 Combina- 
tion Analog Input/Output Board, a combination of 
PROM and RAM memory modules, and an iSBC 201 
Diskette Controller. 

There are various types of I/O devices in this system and 
each will require different FORTRAN-80 I/O support. 
The terminal and disk devices are supported through 
the iSBC 801 run-time package and the RMX/80 high 
level drivers. Communications with the A/D and D/A 
converters is accomplished using internal buffer 
formatting in conjunction with the RMX/80 Analog 
Handlers. Finally, port I/O is used for the digital inputs 
and outputs. 

The next step in the design is to assign the system soft- 
ware functions to individual tasks in a manner that will 
allow for their parallel execution. The following tasks 
will be created to handle this application: 

• STSINP — status input and unit conversion 

• CNTROL - on-line control 

• SCAN and TIMERS — alarm scanning and data 
logging 

• TIMER and TIMUPD - real-time clock 

• CONSOL — operator console handler 

• REPORT — report generation 

Figure 15 shows the interaction of these tasks in the 
RMX/80 system. 



System Considerations 

At this point, let us consider some of the mechanisms this 
system will require to synchronize and co-ordinate the 
tasks we have created. Status and setpoint information 
will be stored in FORTRAN common blocks. This will 
allow the STSINP, CNTROL, SCAN, CONSOL, and 
TIMUPD tasks access to the STATUS information, and 
the CNTROL, SCAN, and CONSOL tasks access to the 
SETPNT information. Once per five minutes, SCAN will 
be notified through a flag byte (MIN5UP) that he is to 
write the current system status to the file TODAYS. RPT. 
Upon command from the operator, REPORT will need to 
read these files to generate reports. 

Since the RMX/80 system is designed to handle asynchro- 
nous events, it is quite possible for any of the tasks to be 
pre-empted at any point in their execution (e.g., an inter- 
rupt occurs or a higher priority task becomes ready to 
run). Thus, the SCAN task may be in the process of 
reading the last byte of a four-byte REAL integer when 
STSINP pre-empts the SCAN task and writes new infor- 
mation into the STATUS common block, thus inval- 
idating the current SCAN operation. In another instance, 
REPORT may be in the process of fetching a disk record 
when SCAN attempts to write to the file. For these 
reasons, and more, it is necessary to implement some sort 
of synchronization mechanism in this system. We will 
insure that at most, one task has access to the common 
blocks and disk records by using a technique called 
mutual exclusion. In the RMX/80 system, this is accom- 
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Figure 15. System Design Diagram 



plished by creating an exchange for each shared resource 
and initially sending one message to it. Any task 
requiring access to the resource first waits at the associ- 
ated exchange for the key message. If a message is at the 
exchange, the task obtains the message and continues 
running until finished and then sends the message back. 
If another task waits at the exchange while the first is pro- 
cessing, it will stop execution until the first task finishes 
and returns the message. 



Code Descriptions 

What follows is a description of the code used to imple- 
ment most of the tasks discussed. Appendix B contains 
fold-out code listings with circled reference letters. In the 
description, sections of the code will be called out using 



circled letters that correspond to symbols in the 
appendix. 

The Semmod Module 

Two PL/M routines called LOCK and UNLOCK perform 
the mutual exclusion operation discussed earlier. There 
are three exchanges used for the purpose of exclusion: 
STSLOK, SETLOK, and DSKLOK. They govern access 
to the STATUS common block, the SETPNT common 
block and the disk file respectively. The LOCK procedure 
(S) takes one parameter, a number representing one of 
the three exchanges, and performs a wait at the appro- 
priate exchange. Note the use of based variables to access 
the parameter. This is necessary since FORTRAN passes 
parameters by reference (address) rather than by value. 
The UNLOCK procedure (B) takes the same para- 
meter and sends the single key (message) back to the 
appropriate exchange. 
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These routines are written in the PL/M language because 
they must deal directly with a few system concepts that 
the FORTRAN-80 language does not. In particular, the 
RQWAIT routine returns to the caller the address of the 
message received from the exchange. In either the PL/M- 
80 or ASM-80 languages this address can be used to 
access the information in the message received. 
FORTRAN-80 routines do not have the capability to use 
address values to access data outside of their own 
module. 



The STSINP Module 

The module STSINP (C) performs the function of 
updating the STATUS common block with new data 
from the sensors that has been converted to engineering 
units. STSINP initializes the FORTRAN-80 math 
routines (D) and directs them to use the default error 
handler. STSINP then calls INIT$IO which initial- 
izes the message that will be used to communicate with 
the RMX/80 Analog Input Handler. The call to 
SMPLIN (F) fills the buffer with analog samples from 
the sensors, and the following DO loop right-justifies 
the 12-bit samples in the 16 bit field (5) . STSINP now 
waits for access to the STATUS block, converts the 
samples, stores them, inputs and stores the values of the 
contact closures and calls UNLOCK (H) . The function 
performed by STSINP is not a continuous function. 
Update of the status information once per second is 
sufficient. The call to WAIT (v) delays execution for 
one second. 



fields of the request message. The definition and usage of 
each of these fields is described in the RMX/80 User's 
Guide. The procedure INIT$IO ® is called by 
STSINP. It simply initializes the analog input request 
message and returns. Note the assignment operation in 
line 29. The RESPONSE$EXCHANGE field of the 
request message must contain the address of the exchange 
where the RMX/80 Analog Handler should send the res- 
ponse to the request (see Figure 1 7 for a diagram of the 
request-response mechanism). In the PL/M language, this 
address is assigned using a location reference - a variable 
name preceded by a period, which stands for the address 
of the variable. FORTRAN-80 routines lack the ability to 
refer to the address of variables. 




Figure 17. Request/Response Mechanism 
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Figure 16. Request Message for Sequential Channel In- 
put with Single Gain 



The ANALOG$IO$MOD Module 

In the module labelled ANALOG$IO$MOD, the declar- 
ation of READ$MSG Q) uses the predefined LITERAL 
called AI$MSG. This LITERAL is one of many in the 
RMX/80 package that can be used to attach meaningful 
symbolic names to PL/M data structures. In this instance, 
AI$MSG defines the fields of a standard analog input 
request message. Figure 16 is a diagram of the individual 



The procedure SMPLIN (L) fills in a buffer, given as an 
input parameter, with analog samples from sequential 
channels on the A/D. Note the mechanism used to handle 
the passing of a FORTRAN string as a parameter. For 
every string in the parameter list, FORTRAN passes the 
starting address- of the string followed by its length in 
bytes. 




Figure 18. Use of EQUIVALENCE Statement 
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The SCAN Module 

The SCAN task is responsible for operator alarms and 
data logging. The EQUIVALENCE statements @ 
cause the STATUS common block to be overlaid by a 
character string, as illustrated in Figure 18. This allows 
for a compact file on disk of numerical data which can 
be broken out later for report generation. 

After mitialization, SCAN waits for access to both the 
STATUS and SETPNT common blocks. Operator alarms 
need to be set only if a parameter is out of specification 
and the effluent pump is on (N) . After performing the 
scan, the variable MIN5UP is checked (3) to see if a 
report should be logged. If so, SCAN gains access to the 
disk file and writes a single record (P) . All locks are 
now released, a one-second delay is counted out, and 
SCAN repeats the whole process. Normally, any errors 
that occur during the execution of I/O statements in the 
run-time package cause a message to be output on the 
console and the offending task to be suspended. Since this 
action is often undesirable, it is wise to handle one's 
errors programatically (Q) . 



The MIN$5$MOD Module 

The module MIN$5$MOD contains two procedures. 
Both routines make use of the timed wait facility in the 
RMX/80 system. Any time a task calls RQWAIT to wait 
for a message at an exchange, an optional time limit (in 
50 msec, intervals) can be specified. This is useful if the 
designer does not wish the task to be hung up forever if 
a message is never sent to that exchange. This mechan- 
ism can also be used to implement a timed wait if an 
exchange is specified to which no one will ever send a 
message. WAIT (R) delays execution of the calling 
task for one second. TIMERS (s) waits for five 
minutes and then sets the variable MIN5UP to signal 
SCAN to log a disk record of current status. 



The REPORT Module 

The system console contains two buttons, one each for 
requests for printouts of today's and yesterday's status 
reports. Whenever one of these two buttons is pushed, the 
CONSOL task sends a message to the PRTREQ 
exchange with the TYPE field indicating which file to 
print. REPORT accepts these messages, checks the TYPE 
field (t) , and calls the FORTRAN subroutine PRINT 
with the appropriate filename as a parameter. It then 
returns the request message to its sender via the response 
exchange field and waits for another request. Figure 1 9 is 
an example of the report generated by this system. 



The PRINT Module 

The PRINT subroutine will read in the compressed 
records written by SCAN and use the same set of EQUIV- 
ALENCE statements to break out the numerical data so 



that it can be formatted for printout. If the type 
field (y) indicates that today's file is being accessed, 
PRINT obtains the key to the DSKLOK exchange since 
SCAN may disturb output operations if it attempts to log 
a new record. If yesterday's file is being accessed, the lock 
is not necessary, since no other task will be accessing this 
file. Once the lock is obtained, a record is read, the digital 
value of the contact closure status is converted to a more 
readable form (v) (ON or OFF), and the status line is 
formatted and printed. Since the SCAN task has an 
important function (operator alarms), we do not wish to 
hold it up for long if it happens to want to log a new status 
record. For this reason, PRINT relinquishes access to the 
file after every tenth record to allow SCAN to log its 
record and continue on. The rest of the code \^ checks 
for end of file indications and returns when printing is 
finished. 

The INITMOD Module 

Last in order (but first in execution) is the INIT proce- 
dure. It is called from the TIMER task, which is the 
highest-priority task in the system (and thus, will be the 
first to execute after start-up). INIT's role in life is to call 
FQOGO (^ to initialize the FORTRAN I/O system, 
send one message to each of the lock exchanges (Y) , and 
initialize the operator alarm panel (z) . The call to 
FQOGO is a requirement for an RMX/80 system in which 
any FORTRAN-80 code that makes use of the iSBC 801 
package is to be executed. The call must be made prior to 
the execution of any FORTRAN-80 I/O or math instruc- 
tions. Also, the call to FQOGO should only be made 
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Figure 19. Sample Output 



SYSTEM GENERATION 
Configuration Module 

Now that all of the code for the individual tasks is written, 
it is time to generate the tables that give the RMX/80 
Executive the information it needs to configure all of the 
tasks and exchanges. Assembly language macros are in- 
cluded in the RMX/80 product to help make building 
the configuration module a little easier. After the 
counters have been initialized, the STD macro is invoked 
several times to define Static Task Descriptors for the 
tasks in the system. Of special note are the last two entries 
(A^ . Any task that uses the FORTRAN I/O system 
must allocate approximately 800 bytes of stack. This 
extra stack space is needed to save information on the 
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current I/O operations. Also, any task performing 
floating point calculations with the software package 
needs to append an extra 1 8 bytes to its Task Descriptor 
as a workspace area. If the iSBC 310 drivers are used 
this need be only 13 bytes long. This last field is de- 
fined by passing a value of 13 or 18 to the optional 
parameter, TDXTRA, in the STD macro. The routines in 
the FORTRAN-80 Run-Time Package require one ex- 
change, FQOLOK, which is allocated using the XCH 
macro (bJ) , and addedjto the Initial Exchange Table 
by the PUBXCH macro @ . 

Controller Addressable Memory Module 

The CAMMOD module @ allocates the blocks of 
memory needed by the RMX/80 Disk File System. 
Specific details on the contents of this module can be 
found in the RMX/80 User's Guide. 



LINK 

Figure 20 shows the ISIS-II LINK command used to bind 
all of the individual modules together with the RMX/80 
libraries needed to implement this application. The 
FORTRAN-80 I/O interface routines are found in the 
library F80RMX.LIB which is part of the iSBC 80 1 pack- 
age, the library FPSFTX.LIB contains the software 
floating point package. If it is desired to accelerate the 
execution of the mathematical operations in this system, 
the iSBC 310 board can be included and the library 
changed to FPHRDX.LIB for iSBC 80/20, 80/20-4, and 
80/30 systems or FPHXIO.LIB for iSBC 80/10 and 
80/ lOA systems. 

The RMX/80 extensions included are the Disk File Sys- 
tem, the Analog Handlers, and the Minimal Terminal 
Handler. 



LOCATE 

After the Link has been finished, the command shown in 
Figure 2 1 is used to invoke the ISIS-II LOCATE program. 
The ORDER statement sets the proper order for all of the 



different segments and common blocks. The common 
blocks themselves are allocated as fixed blocks of 
memory to make possible their shared usage by PL/M 
routines using the AT attribute. This mechanism is 
discussed in greater detail in AP-44, "How to use 
FORTRAN With Other Intel Languages". 



VIL SUMMARY 

The purpose of this application note has been to describe 
the design process used to decide what operating system 
support to use, what language to code programs in, what 
hardware to use and what type of I/O to use to solve a 
given application problem. The specific application ex- 
amples presented have keyed on the use of the 
FORTRAN-80 language. 

The lesson that has been learned is that proper design 
techniques result in the use of the right tool for every job. 
With a complete set of programming languages, each 
optimized for a. specific use, a powerful real-time 
executive, and a complete line of flexible hardware 
products, complicated applications become easy to 
solve. 



LINK !FR:RMX83K.LIB(START) , & 
:F1:X2CFG.0BJ, & 
:F: :RPTMOD.OBJ, & 
:F1:FRTM0D.LIB, & 
:F1: INITMD.OBJ, & 
rFfJrFSti'RUN.LIB, & 
:FP:F8CRMX.LIB, & 
:F0:FPEF.LIB, 6 
:F0: FPSFTX.LIB, & 
:F0:SYSTEM.LIB, (, 

:F0:DFSDIR. LIB (DIRECTORY, DELETE, REMAME, SEEK) , & 
:F0:DIO830.LIB, & 
:FP:DFSUNR.LIB, 6 
:F1:CAM.0BJ, (. 
:F1:PLMM0D. LIB, £, 
:F0:AIHDLR.LIB, 5 
:F0:AOHDLR.LIB, & 
:F0:MTI830.LIB, & 
; F0:MTO830.LIB, & 
:F0:RMX830.LIB, & 
:F0:UNRSLV.LIB, & 
:F0:PLM80.LIB TO : F] : SEWAGE. LK0 PRINT (: FI : SEWAGE. LNK) MAP 



Figure 20. LIN K Command for Sewage Treatment Example 



LOCATE :F1: SEWAGE. LKP' PRINT (: Fl : SEWAGE . LOG) MAP & 
CODE(0) STACKSIZE(0) LINES SYMBOLS PUBLIGS & 
ORDER (GODE DATA /LSTREG/ /STATUS/ /SETPNT/ /MIN5/) 
/SETPNT/(E^FDEH) /MIN5/ (FFEEH) /LSTREG/ (FFA3H) 



/STATUS/ (FFA5H) & 



Figure 21. LOCATE Command for Sewage Treatment Example 
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APPENDIX A 
CODE LISTINGS 
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ASM80 :Fl:DRIVRS.Me0 DEBUG PAGEWIDTH (78 ) PRINT (: F5 : DRIVRS. LST) 
ISIS-II 8080/8085 MACRO ASSEMBLER, V2.0 



DRIVRS PAGE 1 



LOG OBJ 



000D 
000A 
0018 
0018 
007F 
0008 
0013 
0011 
0007 
0012 
00ED 
00EC 
0001 
0002 
0040 
004E 
0027 
00B6 
0092 
00DE 
00DF 
00EB 
0080 
00E0 



SEQ 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 

21 

22 

23 

24 

25 



SOURCE STATEMENT 



CONSOLE I/O ROUTINES FOR FORTRAN-iSBC SYSTEM. 
START INITIALIZES THE HARDWARE AND CALLS THE 
FORTRAN ROUTINE MAINLN. BUFOUT ACCEPTS TWO 
PARAMETERS FROM THE CALLING FORTRAN ROUTINE 
(ACTUALLY ONE FROM THE ROUTINE SINCE PASSING 
A STRING ARGUMENT FROM FORTRAN RESULTS 
IN THE ADDRESS AND LENGTH OF THE STRING BEING 
SENT) AND OUTPUTS THE STRING TO THE USART 
ON THE P0/20. BUFIN TAKES THE SAME TWO 
ARGUMENTS AND FILLS IN THE BUFFER WITH 
CHARACTERS UNTIL <CR> IS ENCOUNTERED. LINE 
EDITING IS PROVIDED TO THE EXTENT THAT 
RUBOUT DELETES A CHARACTER AND ECHOES IT, 
CONTROL-X DELETES THE BUFFER AND STARTS OVER, 
AND CONTROL-R PRINTS THE BUFFER CONTENTS. 
BUFOUT CALLS THE ROUTINE CHKIO TO DETERMINE 
IF A CNTL-S HAS BEEN ENTERED TO CAUSE A PAUSE 
IN THE OUTPUT. IF ENCOUNTERED THE ROUTINE 
WAITS UNTIL A MATCHING CNTL-Q IS ENTERED. 

++++++++++++++++++ + -f++++++ ++++++++ + ++++++f + + + f + + f + + f 4- 



26 CR 

27 LF 

28 ESC 

29 CNTLX 

30 RUBOUT 

31 BS 

32 CNTLS 

33 CNTLQ 

34 BELL 

35 CNTLR 

36 CSTS 

37 CDATA 

38 TXRDY 
3^ RXRDY 
4 RESET 

41 USMODE 

42 USCMND 

43 TIMCMD 

44 CMD55 
4 5 CNTR2 

46 TIMCP 

47 PR8255 

48 STKSIZ 

49 BDFCTR 
50 
51 
52 



EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 



0DH 

0AH 

IBH 

18H 

07FH 

08H 

13H 

IIH 

07H 

12H 

0EDH 

0ECH 

01H 

02H 

4 0H 

4EH 

2 7H 

0B6H 

92H 

0DEH 

0DFH 

0EBH 

128 

224 



ASCII CODE FOR CARRIAGE RET. 

ASCII CODE FOR LINE FEED 

ASCII CODE FOR ESCAPE 

ASCII CODE FOR CONTROL-X 

ASCII CODE FOR RUBOUT 

ASCII CODE FOR BACKSPACE 

ASCII CODE FOR CONTROL-S 

ASCII CODE FOR CONTROL-Q 

ASCII CODE FOR BELL 

ASCII CODE FOR CONTROL-R 

USART COMMAND/STATUS PORT ADD 

USART DATA PORT ADDRESS 

MASK FOR TRANSMITTER READY 

MASK FOR RECEIVER READY 

USART RESET COMMAND 

USART MODE WORD 

USART COMMAND WORD 

BAUD RATE CNTR COMMAND WORD 

825 5 COMMAND WORD 

BAUD RATE CNTR PORT ADDRESS 

TIMER CONTROL PORT ADDRESS 

82 55 COMMAND PORT ADDRESS 

STACK SIZE 

BAUD RATE FACTOR (COUNT VALUE) 



ALLOCATE STACK 



SEQ 



SOURCE STATEMENT 



0P00 317F00 

0003 AF 

0004 D3ED 
0006 D3ED 
0008 D3ED 
000A D3ED 
0r0C 3E40 
C00E D3ED 
0010 3E4E 
0012 D3ED 
0014 3E27 



53 




DSEG 






54 FRTSTK: 


DS 


STKSIZ 


55 








56 
58 E 




LOCAL 


DATA STORAGE 


3UFPTR: 


DS 


2 ; BUFFER POINTER STORAGE 


59 




CSEG 




60 








61 




START- 


-STARTUP ROUTINE PROGRAMS THE USART 


62 






AND TIMER THEN CALLS THE FORTRAN 


63 






ROUTINE. IF THE FORTRAN ROUTINE 


64 






RETURNS START SIMPLY STARTS OVER. 


65 


. 






66 




EXTRN 


MAINLN 


67 i 


START: 


rl.xi 


SP,FRTSTK+STKSIZ-1 ;SET STACK POINTER 


68 




XRA 


A 


ZERO ACCUMULATOR 


69 




OUT 


CSTS 


BRING USART TO KNOWN STATE 


70 




OUT 


CSTS 


BY SENDING FOUR NULLS 


71 




OUT 


CSTS 




72 


/T\ 


OUT 


CSTS 




7 3 


(A) 


MVI 


A, RESET 


RESET USART 


74 


V-y 


OUT 


CSTS 




75 




MVI 


A, USMODE ;SEND USART MODE WORD 


76 




OUT 


CSTS 


77 




MVI 


A, USCMND 


;SEND USART COMMAND 
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0016 D3ED 
0018 3EB6 
001A D3DF 
001C 3EE0 
001E D3DE 
0020 3E00 
0022 D3DE 
0024 3E92 
0026 D3EB 
0028 CD0000 
0P2B C30000 



02E E5 
002F F5 

0030 C5 

0031 60 
C032 69 
0033 228000 
0036 1600 

0038 D5 

0039 CDE200 
003C FE7F 
003E C24700 
0041 CD9000 



LOG OBJ 

0044 C33900 

0047 FEIB 
0049 CAA200 
004C FE12 
004E CAF900 

0051 ID 

0052 C26300 
0055 FE0D 
0057 CA6300 
005A IC 
005B 0E07 
005D CDB400 
0060 C33900 

0063 4F 

0064 CDB400 

0067 71 

0068 23 

0069 14 
006A 3B0D 
006C B9 
006D C23900 

0070 Dl 

0071 CI 

0072 Fl 

0073 El 

0074 C9 



0075 


E5 


0076 


F5 


0077 


60 


0078 


69 


0079 


CDCD00 


007C 


4E 


007D 


CDB400 


0080 


3E0D 


0082 


B9 


0083 


CA8D00 


0086 


23 


0087 


IB 


0088 


7A 


0089 


B3 


008A 


C27900 


008D 


Fl 


008E 


El 


008F 


C9 



® 



78 
79 
8P 
81 
82 
83 
84 
85 
86 
P7 



89 

90 

91 

92 

93 BUFIN: 

94 

95 

96 

97 

9P 

99 
100 
101 
102 
103 ' 
104 
105 
106 
107 



OUT 
MVI 
OUT 
MVI 
OUT 
MVI 
OUT 
MVI 
OUT 
CALL 
^JMP 



CSTS 

A,TIMCMD ;SEND COMMAND WORD 

TIMCP ; 

A,LOW(BDFCTR) ;SEND LOW ORDER BYTE 

CNTR2 ;0F COUNTER VALUE 

A,HIGH(BDFCTR) ;SEND HIGH BYTE OF 



CNTR2 



/COUNTER VALUE 



A,CMD55 ;8255 COMMAND WORD 

PR8255 ; PROGRAM 8255 

MAINLN ;CALL FORTRAN ROUTINE 

START ;IF ROUTINE RETURNS START OVER 



BUFIN—FILLS BUFFER WITH INPUT FROM TERMINAL 



PUBLIC BUFIN 



SEQ 

108 
109 
110 
111 
112 
113 
114 
115 
116 
117 
118 
119 
120 
121 
122 
123 
124 
125 
126 
127 
128 
129 
130 
131 
132 
133 
134 
135 
136 
137 
138 
139 
140 
141 
142 
143 
144 
145 
146 
147 
148 
149 
150 
151 
152 
153 
154 
155 
156 
157 
158 
159 
160 
161 
162 



® 



PUSH 

PUSH 

PUSH 

MOV 

MOV 

SHLD 

MVI 

PUSH 

CALL 
CPI 
JNZ 
CALL 



H 

PSW 

B 

H,B 

L,C 

BUFPTR 

D,0 



CI 

RUBOUT 
BUF05 
DLTCHR 



;SAVE HL PAIR 

;SAVE PSW 

/SAVE BC 

;GET BUFFER POINTER TO HL 

•SAVE IT 

;ZERO TO # CHARACTERS COUNTER 
;NOTE: STRING LENGTH <«255 
/SAVE COUNTERS 

GET CHARACTER 

RUBOUT? 

NO, CONTINUE 

YES, DELETE LAST CHARACTER 



SOURCE STATEMENT 



JMP 

CPI 

JZ 

CPI 

JZ 

DCR 

JNZ 

CPI 

JZ 

INR 

MVI 

CALL 

JMP 

MOV 

CALL 

MOV 

INX 

INR 

MVI 

CMP 

JNZ 

POP 

POP 

POP 

POP 

RET 



GETCHR ;GET NEW ONE 



CNTLX 

DLTLIN 

CNTLR 

PRTBUF 

E 

BUF10 

CR 

BUF10 

E 

CBELL 

ECHO 

GETCHR 

C,A 

ECHO 

M,C 

H 

D 

A,CR 

C 

GETCHR 

D 

B 

PSW 

H 



CONTROL-X? 

YES, DELETE BUFFER 

CONTROL-R? 

YES, PRINT BUFFER 

DECREMENT SPACE LEFT COUNTER 

CONTINUE IF COUNTER > 

IF THIS END OF LINE ALL IS OK 

BRING COUNTER BACK ONE 
NOT OK, ECHO BELL 

GET NEW CHARACTER 

MOVE CHARACTER TO C 

AND ECHO IT 

STORE IT IN BUFFER 

INCREMENT BUFFER POINTER 

INCREMENT # OF CHARS COUNTER 

IS IT A NEWLINE CHARACTER 

NO, CONTINUE FILLING 
YES, RETURN 



BUFOUT ENTRY POINT 



f^UBLIC 
BUFOUT: PUSH 

I PUSH 
MOV 
MOV 
OUTCHR: CALL 
MOV 
CALL 

©MVI 
INX 
DCX 
MOV 
ORA 
JNZ 
EXITLP': POP 
POP 
RET 



P: PC 
I PO 
I RE 



BUFOUT 

H 

PSW 

H,B 

L,C 

CHKIO 

C,M 

ECHO 

A,CR 

C 

EXITLP 

H 

D 

A,D 

E 

OUTCHR 

PSW 

H 



SAVE HL REGISTER PAIR 

SAVE PSW 

GET STRING POINTER INTO HL 

CHECK FOR PAUSE (CNTL-S) 
GET CHARACTER 
OUTPUT TO TERMINAL 
IS IT A <CR>? 

YES EXIT 

INCREMENT POINTER 

DECREMENT STRING COUNT 

GET HI BYTE 

AND WITH LO BYTE 

IF STRING COUNT <> CONTINUE 

RESTORE PSW 

RESTORE HL 

ALL THROUGH 



DLTCHR— DELETES LAST CHAR ENTERED INTO BUFFER 



/DECREMENT # OF CHARS COUNTER 
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LOG OBJ 



SOURCE STATEMENT 



0091 F29B00 

0094 14 

0095 0E07 
0097 CDB400 
009A C9 

009B IC 
009C 2B 
009D 4E 
009E CDB400 
00A1 C9 



00A2 0E23 
00A4 CDB400 
00A7 0E0D 
00A9 CDB4 00 
00AC 2A8000 
00AF Dl 
00B0 D5 
00&1 C33900 



00B4 41 
00B5 3E1B 
00B7 B8 
00B8 C2BD00 
00BB 0E24 

00BD CDEE00 
00C0 3E0D 
00C2 Be 
0003 C2CB00 
00C6 0E0A 
00C8 CDEE00 

00CB 48 
00CC 09 



00CD 
00CF 
00D1 
00D2 
00D4 
00D6 
00D8 
00D9 
00DC 
00DE 
00E1 



DBED 

E602 

08 

DBEC 

E67F 

FE13 

00 

ODE200 

FEJl 

O2D900 

09 



163 

164 

165 

166 

167 

168 DLTC10: 

169 

170 

171 

172 

173 

174 

175 

176 

177 DLTLIN: 

178 

179 

180 

181 

182 

183 

184 

185 

186 

187 

188 

189 ECHO: 

190 

191 

192 

193 

194 ECH05: 

195 

196 

197 

198 

199 

200 

201 ECH10: 

202 

203 

204 

205 

206 

207 CHKIO: 

208 

209 

210 

211 

212 

213 

214 WAIT40: 

215 

216 

217 



JP 

INR 

MVI 

CALL 

RET 

INR 

DCX 

MOV 

CALL 

RET 



DLTC10 
D 

CBELL 
ECHO 



E 
H 

C,M 
ECHO 



IF >=0 CONTINUE 

RUBOUT PAST START OF BUFFER 

INCREMENT COUNT, ECHO A BELL 

AND RETURN 

INC. SPACE LEFT INDICATOR 
DECREMENT BUFFER POINTER 
ECHO DELETED CHARACTER 

AND RETURN 



DLTLIN — DELETES LINE BUFFER AND BEGINS REFILL 



MVI C,'#' 
CALL ECHO 
MVI C,CR 
CALL ECHO 



LHLD 
POP 
PUSH 
JMP 



BUFPTR 

D 

D 

GETCHR 



;ECHO A CRLF 

;GET ORIGINAL POINTER BACK 

;GET COUNTERS BACK 

; RES AVE 

;GET NEW CHARACTERS 



ECHO— ECHOES CHARACTERS TO THE TERMINAL 



MOV 
MVI 
CMP 
JNZ 
MVI 

CALL 

MVI 

CMP 

JNZ 

MVI 

CALL 

MOV 
RET 



B,C ;SAVE ARGUMENT 

A, ESC ;SEE IF ECHOING AN 

B /ESCAPE CHARACTER 

ECH05 ;NO--BRANCH 

0, •$' ; YES, ECHO AS '$' 



CO 

A, OR 

8 

ECH10 

C,LF 

CO 



;OUTPUT IT 

CHARACTER ECHOED A CR? 

NO — SPECIAL ACTION NOT NEEDED 

YES — ECHO FREE LINE FEED 



;RESTORE ARGUMENT 



CHKIO — CHECKS FOR CNTL-S OPERATION 



IN 

AN I 

RZ 

IN 

AN I 

CPI 

RNZ 

CALL 

CPI 

JNZ 

RET 



CSTS 
RXRDY 

CDATA 

7FH 

ONTLS 

01 

ONTLQ 

WAIT4Q 



GET STATUS 

CHARACTER AVAILABLE? 

NO, RETURN 

YES, GET CHARACTER 

STRIP OFF PARITY 

CONTROL-S? 

NO, IGNORE IT 

YES, WAIT FOR A CONTROL-Q 



GOT IT, RETURN 



LOO 


OBJ 


SEC 
218 




SOURCE 


STATEMENT 








219 




CI— ENTER CHARACTER FROM TERMINAL 






220 










EeE2 


DBED 


221 


CI: 


IN 


CSTS 


GET STATUS BYTE 


00E4 


E6fi2 


222 




ANI 


RXRDY 


CHARACTER AVAILABLE 


00E6 


CAE2P0 


C 223 




JZ 


CI 


NO, LOOP 


00E9 


DBEC 


224 




IN 


CDATA 


READY, GET CHARACTER 


?0EB 


E67F 


225 




ANI 


P7FH 


STRIP OFF PARITY 


00ED 


09 


226 
227 




RET 










228 


. 


CO— OUTPUT CHARACTER IN REGISTER TO TERMINi 






229 


; 








C0EE 


DBED 


230 


CO: 


IN 


CSTS 


GET STATUS BYTE 


00F0 


E601 


231 




ANI 


TXRDY 


TRANSMITTER READY? 


00F2 


CAEE00 


C 232 




JZ 


CO 


NO, LOOP 


00F6 


79 


233 




MOV 


A,C 


YES, MOVE CHARACTER TO ACC. 


00F6 


D3EC 


234 




OUT 


CDATA 


SEND TO TERMINAL 


00F8 


C9 


235 
236 


; 


RET 










237 




PRTBUF 


—PRINTS 01 


JRRENT BUFFER (CONTROL-R) 






238 


• 












239 


PRTBUF 








00F9 


0E0D 


240 




MVI 


COR 


•ECHO CRLF 


00FB 


CDB/'C0 


C 241 




CALL 


ECHO 




00FE 


E5 


242 




PUSH 


H 


;SAVE CURRENT BUFFER POINTER 
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OflFF 2A80f^fi 


D 


243 




LHLD 


BUFPTR 


0102 D5 




244 
24 5 


PRLOOP: 


PUSH 


D 


ei03 15 




246 




DCR 


D 


P104 FA0F01 


c 


247 




JM 


PREXIT 


01P7 4E 




248 




MOV 


C,M 


0108 CDB400 


C 


249 




CALL 


ECHO 


0ieB 23 




250 




INX 


H 


010C C3?301 


c 


251 
252 


PREXIT: 


JMP 


PRLOOP 


P10F Dl 




253 




POP 


D 


0110 El 




254 




POP 


H 


0111 r33900 


c 


255 
256 




JMP 
END 


GETCHR 



;GET POINTER TO BEGINNING 
;SAVE CURRENT COUNTERS 

DECREMENT COUNTER 

NO MORE CHARACTERS IN BUFFER 

GET CHARACTER 

ECHO IT 

INCREMENT POINTER 

LOOP UNTIL ALL CHARS OUTPUT 

RESTORE COUNTERS 
RESTORE POINTER 
GET NEW CHARACTER 



FORTRAN COMPILER 



10/12/78 PAGE 



ISIS-II FORTRAN-80 COMPILATION OF PROGRAM UNIT MAINLN 

OBJECT MODULE PLACED IN : Fl : MAINLN. OBJ 

COMPILER INVOKED BY: FORT80 : F 1 :MAINLN . FRT DEBUG DATE ( 10/12/78) PAGEWIDTH (78) 



®. 



UBROUTINE MAINLN 

MPLICIT LOGICAL (A-Z) 
C 

C — MAINLINE ROUTINE FOR TEST STAND SOFTWARE. COMMAND LINE IS 
C — SEARCHED FOR KEYLETTER AND APPROPRIATE ROUTINE IS CALLED. 
C~ ALL UNUSED LETTERS TRAP TO ERROR ROUTINE. 



CHARACTER LINBUF (80 ) * 1 , IMAGE*80 

INTEGER INDEX* 2, GARRET* 1,KEYLTR*1,ERRFLG* 2, DUMMY* 2 

COMMON /LINE/ LINBUF , INDEX , GARRET 

EQUIVALENCE (LINBUF, IMAGE ) 

DATA GARRET /I 3/ 
C 
C-- INITIALIZE SYSTEM 

C 

k DUMMY=^ 
J CALL FQFSET (DUMMY, DUMMY) 
C ' 
C — WRITE BANNER 



©■ 



■'© 



1 WRITE(IMAGE,1R,I0STAT=ERRFLG,ERR=999) GARRET 

10 FORMAT ('TEST STAND V0.0',A) 
C 

- OUTPUT BUFFER 
C 

CALL BUFOUT (IMAGE) 
C 
C — INITIALIZE INDEX POINTER TO START OF LINBUF 



20 



INDEX=1 



PROMPT OPERATOR 



14 WRITE (IMAGE, 30, IOSTAT=ERRFLG,ERR=999) GARRET 

15 30 FORMAT( 'COMMAND?', A) 

16 CALL BUFOUT(IMAGE) 






C — GET COMMAND LINE 

CALL BUFIN (IMAGE) 
POSITION INDEX TO FIRST NON-BLANK CHARACTER 
CAElL DBLANK 



C~ CONVERT KEYLETTER TO NORMALIZED INTEGER VALUE IE. 



KEYLTR=ICHAR (LINBUF (INDEX) )-#4 0H 
INDEX=INDEX+1 



C — CHECK FOR INVALID CHARACTERS 
C 

21 IF(KEYLTR.GE. 1) THEN 

22 IF(KEYLTR.LE.#1AH) THEN 
C 

C — IF VALID CHARACTER JUMP TO PROPER HANDLING ROUTINE 

C 

C ABCDEFGHIJKL/viN 

GOTO (30 0, 10 0, lO0,30f,100,100,100,]0Pi,100,10f,lCC",100,30 0,10O, 
C OPQRSTUVWXYZ 

C100, 10 0,100, 100, 30 0,20 0,10?;, 100, 100, 100, 100, 100) KEYLTR 



'® 



2-55 



24 ENDIF 

2 5 ENDIF 

C 

C-- IF INVALID OUTPUT ERROR AND GET NEW LIME 

C 

26 WRITE(IMAGE,40,IOSTAT=ERRFLG,ERR=999) CARRET 

27 40 FORMAT {'INVALID KEYLTR',A) 

28 CALL BUFOUT(IMAGE) 

29 GOTO 20 
C 

C — CONTROL BRANCHES TO ONE OF THESE BAGED ON KEYLETTER 

C 

C 

C — STATEMENT LINE IKP. IS USED TO TRAP ALL KEYLETTERS NCT USED 

C 

30 100 WRITE(IMAGE,n0,IOSTAT=ERRFLG,ERR=999) CARRET 

31 lie FORMATCNO SUCH TEST', A) 

32 CALL BUFOUT(IMAGE) 

33 GOTO 20 
C 

C— TRANSITION TEST 
C 
200 CALL TRANST 
GOTO 2 

CALCULATOR MODE 



"®. 



36 300 CALL MATH 

37 GOTO 20 
C 

C-- ERROR HANDLER 
C 

38 999 CALL ERROR (ERRFLG ) 

39 GOTO 1 

40 END 



ISIS-II FORTRAN-80 COMPILATION OF PROGRAM UNIT DBLAMK 

OBJECT MODULE PLACED IN : F] : DB LANK . OBJ 

COMPILER INVOKED BY: FORTP0 : F] : DB LANK . FRT DEBUG DATE fl iV ] 2/7'P ) PAGEWI DTH f 7 8 ) 



®SUB 
IMP 



1 IIVU SUBROUTINE DBLANK 

2 ^*-^ IMPLICIT LOGICAL (A-Z) 

C 

C-- POSITIONS INDEX TO NEXT NON-BLANK CHARACTER IN LINBUF 

C 

3 INTEGER INDEX*2 , CARRET* 1 , ERRFLG*2 

4 CHARACTER LINBUF (80 )* 1 , IMAGE *8 , ENDLIN* 1 

5 EQUIVALENCE (LINBUF , IMAGE) ,( ENDLIN , CARRET) 

6 COMMON /LINE/ LINBUF , INDEX , CARRET 
C 

7 1 IF(LINBUF(INDEX) .EQ.ENDLIN) GOTO ? 

8 IF(LINBUF(INDEX) .NE. • ') RETURN 

9 INDEX=INDEX+J 

10 IF(INDEX.LE.7?) GOTO 1 

C 

C — IF END OF LINE ASK FOR MORE PARAMETERS 
C 

WRITE (IMAGE, 3 , IOSTAT=ERRFLG , ERR=999) CARRET 

FORMAT( 'MISSING PARAMETER , PLEASE ENTER', A) 

CALL BUFOUT(IMAGE) 

CALL BUFIN (IMAGE) 

INDEX=1 

GOTO 1 
C 

C — ERROR HANDLER 
C 

17 999 CALL ERROR (ERRFLG ) 

18 RETURN 

19 END 



!SI^-II FORTRAN-8?' CO-viPI LATION OF PROGRAM UNIT ERROR 

OBJECT MODULE PLACED IN : F 1 : ERROR . OBJ 

ro.'viPILER INVOKED PY: FORT?,' : F] : ERROR . FRT DEBUG DATE (] 0/ 1 2/78 ) PAGEWIDTH ( 78 ) 



11 


2 


12 


3 


13 




14 




15 




16 





©SUBROUTINE ERROR (ERRNU 
I.MPLK'IT L0GICAL(A-7) 



OUTPUT ERROR MESSAGE 
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CHAHACTf:R IMAGE*?C,LINBUFfn0)*l 
INTEGER ERRNUM*2, INDEX* 2 , GARRET* 1 
EQUIVALENCE ( L INBUF , IMAGE ) 
COMMON /LINE/ LINBUF , INDEX, GARRET 

WRITE (IMAGE, 10) ERRNUM , GARRET 

FORMATf ' ***ERROR*** #',I4,A) 

GALL BUFOUT (IMAGE) 

RETURN 

END 



ISIS-II F0RTRAN-8(' COMPILATION OF PROGRAM UNIT MATH 

OBJECT MODULE PLACED IN :F]:MATH.OBJ 

COMPI[,ER INVOKED BY: FORTP(^ :F]:MATH.FRT DEBUG DATE ( Id/l 2/78 ) PAGEWIDTH (73 ) 



©SUBROUTINE MATH 
IMPLICIT LOGICAL (A-Z 



C — IMPLEMENTS CALCULATOR MODE 
C 

1 INTEGER INDEX*2, GARRET*] , ERRFLG*2 

4 CHARACTER LINBUF (8(^ )* 1 , IMAGE *8 , COMMND* 1 , SYMBOL* 1 

5 REAL OPl ,0P2, RESULT 

<--, EQUIVALENCE ( LI NBUF , IMAGE ) 

7 COMMON /LINE/ L INBUF , INDEX , GARRET 

C 

C — RESCAN KEYLETTER TO DETERMINE OPERATION 



®INDEX=INDEX-1 
COMMND=LINBUF (INDEX) 
INDEX=INDEX+] 



'© 



MOVE INDEX TO FIRST OPERAND 

CALL DBLANK 

GET IT IN 

CALL CONVRT (OPl ) 

REPEAT FOR SECOND OPERAND 

CALL DBLANK 

CALL C0NVRT(0P2) 



C — PERFORM OPERATION 
G 

]S IF(COMMND. EO. 'M' ) THEN 

1 P' RESULT = 0P1*0P? 

17 SYMB0L='*' 

18 GOTO U 

19 END IF 
C 

2C I F(GOMMND. EQ. 'D' ) THEN 

21 RESULT=0P]/0P2 

2 2 SYMBOL='/' 
2 3 GOTO Jl 

?A ENDIF 

G 

25 IF(COMMND.EC. 'A' ) THEN 

?r-, RESULT=0P]+0P2 

27 SYMBOL='+' 

28 GOTO 11 

29 FNDIF 
C 

30 IF(COMMND. FQ. 'S ' ) THEN 



31 RESULT=0P1-0P2 

32 SYMBOL='-' 

33 GOTO 11 

34 ENDIF 

C 

C-- OUTPUT RESULTS 

C 

35 11 WRITEdMAGE, 12, IOSTAT=ERRFLG,ERR=999) OPl , SYMBOL , 0P2 , RESULT , 

ICARRET 

36 12 F0RMAT(Fia. 5, IX, A, 1X,F.18. 5, IX, ' = ' , 1X,F18. 5,A) 

37 CALL BUFOUT (IMAGE) 
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38 RETURN 
C 

C — ERROR HANDLER 
C 

39 999 CALL ERROR (ERRFLG) 
4 RETURN 

41 END 



FORTRAN COMPILER 10/12/78 PAGE 1 

ISIS-II FORTRAN-80 COMPILATION OF PROGRAM UNIT CONVRT 

OBJECT MODULE PLACED IN : Fl :CONVRT. OBJ 

COMPILER INVOKED BY: F0RT8P : Fl :CONVRT. FRT DEBUG DATE ( 10/1 2/78) PAGEWIDTH (78 ) 

1 (R) SUBROUTINE CONVRT (VALUE) 

2 Vw/ IMPLICIT LOGICAL(A-Z) 
C 

C~ INPUTS NEXT PARAMETER IN LINBUF 
C 

3 INTEGER I * 1 , INDEX*2 ,TMPIND*1 , GARRET* 1 , ERRFLG*2 

4 REAL VALUE 

5 CHARACTER LINBUF (80 ) *1 ,TMPBUF ( 20) * 1 , BUFFEH*20 , ENDLIN*! 

6 EQUIVALENCE (TMPBUF, BUFFER) , (ENDLIN, GARRET) 

7 COMMON /LINE/ LINBUF, INDEX, GARRET 
C 

C— INITIALIZE 
C 

8 DO 21 1=1,19 

9 21 TMPBUF(I)=' • 

10 TMPBUF ( 20) =ENDL1N 

11 TMPIND=1 
C 

C— FILL BUFFER UNTIL COMMA OR ENDLINE ENCOUNTERED 

12 22 TMPBUF(TMPIND)=LINBUF(INDEX) 

13 INDEX=INDEX+1 

14 TMPIND=TMPIND+1 

15 ^*-^^ IF(LINBUF(INDEX) .EO. ' ,' ) THEN 

16 ( C;.^ INDEX=INDEX+1 

17 \2/ GOTO 23 

18 ENDIF 

19 IF(LINBUF(INDEX) .EQ. ENDLIN) GOTO 23 

20 I GOTO 22 
C ^^ 

C— - READ UNDER FORMAT CONTROL 



21 y^-^. 23 READ(BUFFER,24,IOSTAT=ERRFLG,ERR=999) VALUE 

22(Tj24 F0RMAT(F19.5) 

2 3 Vw^ RETURN 

C 

C— ERROR HANDLER 

C 

24 999 CALL ERROR (ERRFLG) 

2 5 RETURN 

26 END 



ISIS-II FORTRAN-80 COMPILATION OF PROGRAM UNIT TRANST 

OBJECT MODULE PLACED IN : Fl rTRANST. OBJ 

COMPILER INVOKED BY: FORT80 : Fl : TRANST. FRT DEBUG DATE ( 1 0/1 2/78 ) PAGEWIDTH (78 ) 



1 SUBROUTINE TRANST 

2 IMPLICIT LOGICAL (A-Z) 
C 

C— PERFORM TRANSITION TESTING 
C 

3 REAL START, STOP, STEP, TOL, TEMP, VOLTAG, VCC(20) , 
1LOWLVL{20) ,LOTOHI (20) ,HILVL(20) ,HITOLO(20) 

C 

4 INTEGER CARRET*1 , ITEMP*2 ,TSTlNP*2 , SAMPLE*2 , 

1 LSTSAM* 2 , DELTA* 2 , ERRFLG * 2 , PNTCNT* 1 , 1 NDEX* 2,1*1 
C 

5 CHARACTER LINBUF (80) *1 , IMAGE*80, TEST (20) *^ 
C 

6 EQUIVALENCE (LINBUF, IMAGE ) 
C 

7 COMMON /LINE/ LINBUF , INDEX, GARRET 
C 

C— INITIALIZE 
C 



2-58 



8 DO 5, 1=1,20 

9 5 TEST (I )=• PASSED' 

10 TSTINP=0 

11 PNTCNT=1 
C 

C — SCAN COMM/^ND TAIL FOR PARAMETERS 

C 

C VCC START STOP STEP TOLERANCE 

C 

12 CALL DBLANK 

13 CALL CONVRT (START) 

14 CALL DBLANK 

15 CALL CONVRT (STOP) 

16 CALL DBLANK 

17 CALL CONVRT(STEP) 

18 CALL DBLANK 

19 CALL CONVRT (TOL) 
C 

C-- IF (STOP-START) /STEP YIELDS MORE THAN 20 STEPS 

C-- OUTPUT MESSAGE AND RETURN 

C 

20 IF(IFIX( (STOP-START)/STEP) .GT.20) THEN 

21 WRITE.(IMAGE,10,IOSTAT=ERRFLG,ERR=999) GARRET 

22 If' FORMAT ('TOO MANY POINTS', A) 

23 CALL BUFOUT(IMAGE) 

24 RETURN 

25 ENDIF 
C 

C — GET TEMPERATURE AND LINEARIZE 
C 

26 ^^^ CALL ADCIN(ITEMP,e) 

27 /|n TEMP=98.63*AL0G(FL0AT(1TEMP) )+13.5^. 
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C-- OUTPUT HEADER 

r 

2? WRITEaMAGE,2 0,IOSTAT=ERRFLG,ERR=999) TOL, TEMP, GARRET , GARRET 

29 2C FORMATf 'TRANSITION TEST TOLERANCE= ' , F5 . 1 , 

J'% AMBIENT TEMPERATURE = •,F6.2,' DEGREES C',A,A) 
3? CALL BUFOUT (IMAGE) 

?1 WRITE (IMAGE, 30, IOSTAT=ERRFLG,ERR=999) GARRET, GARRET 

32 30 FORMAT(' VCC HIGH TRANS LOW TRANS HIGH LOW TEST' 

]A,A) 

33 CALL BUFOUTdMAGE) 
C 

C-- BEGIN TEST; OUTPUT STARTING VCC V/^LUE 
C 

3^ VOLTAG=START 

3 5 4 VCC(PNTCNT)=VOLTAG 

3G CALL DACOUT(IFIX(VOLTAG*409.6) ,0) 

C 
C-- OUTPUT ZERO VOLTS TO TEST INPUT 

CALL DACOUT(TSTINP, 1) 

-- GET ONE SAMPLE 
C 
3P CALL ADCIN (SAMPLE, 1) 

C 

C-- MAKE IT THE LAST SAMPLE AND ALSO STORE IT 
C 

30 LSTJ-'AM=SAMPLE 

40 LOWLVL (PNTCNT) =FLOAT (SAMPLE) *409. 6 

r 

C-- BEGIN LOOP LOOKING FOR LOW TO HIGH TRANSITION 
C 

4 1 50 TSTINP=TSTINP+1 

4 2 CALL DAC0UT(TSTINP,1) 
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C-- GET SAMPLE 

C 
4^ CAL[. ADC IN (SAMPLE, ] ) 

fi& DELTA=SAMPLE-LSTSAM 

C 

C-- SEE If TRANSITION;DELTA .GT. 2.2 VOLTS 

C 
f", r F (DELTA. LT. 901) THEN 

4H LST5AM=SAMPLE 

C 

C-- NO TRANSITION; IF TSTINP NOW UP TO 5.5V AND NO TRANSITION 

C-- OUTPUT MESSAGE INDICATING DEAD PART AND RETURN 

4-7 IF(TSTINP.GE.2251) THEN 
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WRITE(IMAGE,^0,IOSTAT=ERRFLG,ERR=99 9) GARRET 

FORMAT('DEAD PART, NO TRANSITION ', A) 

CALL BUFOUT(IN^AGE) 

RETURN 

ENDIF 

CONTINUE LOOP 



C 

53 GOTO 50 

54 ENDIF 
C 

C — TRANSITION; ASSIGN ARRAY ELEMENT 
C 

55 LOTOHI{PNTCNT)=FLOAT(T-STINP)/4 09.6 
C 

C-- CHECK TOLERANCE 
C 
5 6 IF( (LOTOHI (PNTCNT) .GE. ( . 8- (TOL/] (50 . * . «) ) ) .AND. 

KLOTOHI (PNTCNT) .LE. (.8+(TOL/100.*.8) ) ) ) GOTO 70 
C 

C — TEST FAILED 
C 

57 TEST{PNTCNT)='FAILED' 
C 

C — BEGIN HIGH TO LOW TEST 

C 

C 

C — OUTPUT 5.0 VOLTS 

C 

58 70 TSTINP=2048 

59 CALL DAC0UT(TSTINP,1) 
C 

C — GET SAMPLE 
C 

60 CALL ADCIN (SAMPLE) 
C 

C — MAKE IT LAST SAMPLE AND ALSO STORE IT 
C 

61 LSTSAM=SAMPLE 

62 HILVL (PNTCNT) =FLOAT (SAMPLE) *409.6 
C 

C — BEGIN LOOP LOOKING FOR HIGH TO LOW TRANSITION 
C 

63 80 TSTINP=TSTINP-1 

64 CALL DAC0UT(TSTINP,1) 
C 

C — GET SAMPLE 
C 

65 CALL ADCIN (SAMPLE, ] ) 

66 DELTA=LSTSAM-SAMPLE 
C 

C — SEE IF TRANSITION; DELTA .GT. 2.2 VOLTS 
C 

67 IF(DELTA.LT.901) THEN 

68 LSTSAM=SAMPLE 
C 

C— NO TRANSITION; CHECK TO SEE IF VOLTAGE DOWN TO ZERO 
C 

69 IF(TSTINP.LE.0) THEN 
C 

C — YES; OUTPUT DEAD PART MESSAGE 
C 

70 WRITE(IMAGE,60,IOSTAT=ERRFLG,ERR=999) CARRET 

71 CALL BUFOUT (IMAGE) 

72 RETURN 

73 ENDIF 
C 

C — CONTINUE LOOP 

C 
lA GOTO 8C 

75 ENDIF 

C 

C — TRANSITION; ASSIGN ARRAY ELEMENT 

r 
7P HITOLO(PNTCNT)=FLOAT(TSTINP)*^09.6 

C 

C-- CHECK TOLERANCE 

C 
7 7 IF( (HITOLO (PNTCNT) .GE. (3. 5- (TOL/1 0e . * 3 . 5 ) ) ) .AND. 

1 (HITOLO(PNTCNT) .LE. (3.5+(TOL/100.*3.5) ) ) ) GOTO 90 

C 

C — TEST FAILED 
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78 TEST(PNTCNT) ^'FAILED' 
C 

C-- INCREMKNT VCC AND IF MOT .GT. STOP CONTINUE 
C 

79 91' VOLTAG=VOLTAG + STEP 

?t? IF (VOLTAG.LE.STOP) THEN 

8] PNTCNT=PNTCNT+1 

e? TSTINP = (i 

8 3 GOTO AP 

3^ ENDIF 

C-- TEST COMPLETE; OUTPUT RESULTS 

C 

85 DO ] 1C,I = ] ,PNTCNT 

Sr. WRITE(IMAGE,10e,IOSTAT = ERRFLG,ERR=999) VCC(I), 

ILOTOHI (I) ,HITOLO(I) ,HILVL(I ) ,LOWLVLfl) , TEST (I) ,CARRET 

a? IPt^ FORMATf3X,F5.2,3X,F'^.2,6X,F6.2,3X,F6.2,lX,F6.2,2X,6A,A) 

VP Jlf' CALL BUFOUT(IMAGE) 

89 RETURN 

C 

C-- ERROR HANDLER 





c 




90 


999 


CALL ERROR (ERRF LG 


91 




RETURN 


92 




END 
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SUBROUTINE ADCIN (VALUE , CHAN ) 



C-- ROUTINE TO INPUT SINGLE VALUE FROM A/D CONVERTER CHANNEL 
C-- GIVEN AND RETURN IT IN VALUE FIELD. 

INTEGER*? VALUE 

INTEGER*! CHAN 
SINCLUDE (: Fl rADCDAC.DEC) 
C 
C — DEFINITIONS OF tsbC 732 REGISTERS 



C — COMMAND STATUS REGISTER 
C 

INTEGER*! CMDSTS 
C 

C — MUX ADDRESS REGISTER 
C 

INTEGER*! MUXADR 
C 

C-- LAST CHANNEL REGISTER 
C 

INTEGER*! LSTCHN 
C 

C-- CLEAR INTERRUPT COMMAND WORD 
C 

INTEGER*! CLRINT 
C 

C-- ADC DATA REGISTER 
C 

INTEGER*2 ADCDAT 
C 

C-- DAC P DATA REGISTER 
C 

INTEGER*2 DAC? 
C 

C-- DAC 1 DATA REGISTER 
C 

INTEGER*2 DAC! 
C 

C-- SET UP COMMON BLOCK 
C 

COMMON /ADC/ CMDSTS , MUXADR , LSTCHN , CLRINT, ADCDAT, DAC0 , DAC! 
C 

C — SET UP CHANNEL ADDRESS 
C 

MUXADR=CHAN 
C 

C-- START CONVERSION 
C 

CMDSTS=#1H 
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C-- WAIT FOR END OF CONVERSION 

C 
] "^ ] IF( (CMDSTS.AND.«8CH) .NF,. I80H) GOTO 1 

C 

C-- GET DATA IN 

C 
in VALUE=ADCDAT 

C 

C — RIGHT JUSTIFY AND CONVERT TO COUNTS 

C 

17 VALUE=VALUE/16 

18 IF(VALUE.LT.n) VALUE=VALUE+4096+l 

19 RETURN 

20 END 
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SUBROUTINE DACOUT (VALUE , CHAN) 
C 

C— OUTPUTS VALUE TO D/A CONVERTER 
C 

2 TNTEGER*2 VALUE, CHAN 

3 $INCLUDE(:F1:ADCDAC.DEC) 
= C 

= C-- DEFINITIONS OF ISBC 732 REGISTERS 

= C 

= C 

= C— COMMAND STATUS REGISTER 

= C 

4 = INTEGER*! CMDSTS 
= C 

= C— MUX ADDRESS REGISTER 
= C 

5 = INTEGER*! MUXADR 
= C 

= C — LAST CHANNEL REGISTER 
= C 

6 = INTEGER*! LSTCHN 
= C 

= C — CLEAR INTERRUPT COMMAND WORD 
= C 

7 = INTEGER*! CLRINT 
= C 

= C— ADC DATA REGISTER 
= C 

8 = INTEGER*2 ADCDAT 
= C 

= C— DAC DATA REGISTER 
= C 

9 = INTEGER* 2 DAC0 
= C 

= C — DAC ! DATA REGISTER 
= C 
10 = INTEGER*2 DAC! 
= C 

= C— SET UP COMMON BLOCK 
= C 
1! = COMMON /ADC/ CMDSTS , MUXADR, LSTCHN , CLRINT, ADCDAT, DAC0 , DAC! 

C 

C — OUTPUT VALUE TO PROPER CHANNEL 

C — AFTER SHIFTING INTO HIGH ORDER 12 BITS 

C 

12 IF (VALUE. LT.0) VALUE=VALUE+4096+l 

13 VALUE=VALUE*!6 

14 IF(CHAN.EQ.0) DAC0=VALUE 

15 IF(CHAN.EC.I) DAC!=VALUE 

16 RETURN 

17 END 
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APPENDIX B 
CODE LISTINGS 
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1 SEMAPHORES: 

DO; 

Contains LOCK and UNLOCK procedures for 
manipulating semaphores. Called by FORTRAN 
routines with one parameter; the address of 
the index of the semaphore to be operated on. 

************************************************** 
Snolist 

17 1 DECLARE (stslok ,setlok ,dsklok) (10) BYTE PUBLIC; 

18 1 DECLARE semaphored) ADDRESS PUBLIC DATA ( 

.stslok , 
.setlokr 
.dsklok); 

19 1 DECLARE token (3) STRUCTURE ( 

link ADDRESS, 

length ADDRESS, 

type ADDRESS) PUBLIC; 

20 1 LOCK: PROCEDURE (semaSnumberSptr) REENTRANT PUBLIC; 

DECLARE semaSnumberSptr ADDRESS; 

DECLARE sema$number BASED semaSnumberSptr BYTE; 

DECLARE msg$ptr ADDRESS; 
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2 


23 


2 


24 


2 


25 


2 


26 


2 


27 


1 


28 


2 


29 


2 


30 


2 


31 


2 


32 


2 


33 


1 
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msg$ptr=RQWAIT (semaphore (semaSnumber) ,P) ; 

RETURN; 

END; 

UNLOCK: PROCEDURE (semaSnumberSptr) REENTRANT PUBLIC; 

DECLARE sema$number$ptr ADDRESS; 

DECLARE sema$number BASED semaSnumberSptr BYTE; 

CALL RQSEND (semaphore (semaSnumber) , .token (semaSnumber) 
D\ RETURN; 

^J END; 

END SEMAPHORES; 
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1 (CJ SUBROUTINE STSINP 

2 N-X IMPLICIT LOGICAL (A-Z) 

C 

C — TASK CODE FOR STATUS INPUT TASK. UPDATES STATUS COMMON 

C— BLOCK WITH ANALOG AND DIGITAL DATA VALUES. ALSO DOES 

C~ ANALOG COUNT TO ENGINEERING UNIT CONVERSIONS. 

C 

3 CHARACTER SMPLBF*22,CLOCK*l 2 

4 INTEGER*2 SAMPLS (11) , DUMMY 

5 REAL ANDATA(ll) 

6 EQUIVALENCE (SMPLBF,SAMPLS) 

7 INTEGER*! DIGDAT,I 

8 COMMON /STATUS/ ANDATA,DIGDAT, CLOCK 
C 

C— INITIALIZE FLOATING POINT LIBRARIES 

9 ( Dj DUMMy=0 

10^*-^ CALL FQFSET (DUMMY, DUMMY) 
C 
C — CALL INITIALIZATION ROUTINE 
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CALL INITIO 
C 

C— CALL ROUTINE TO INPUT SAMPLES 
C 

CALL SMPLIN(SMPLBF) 



SHIFT SAMPLS TO RIGHT JUSTIFY 
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15 ^^-^50 



DO 50 1=1,11 

SAMPLS(I)=SAMPLS(I)/16 

IF(SAMPLS(I) .LT.0) SAMPLS (I ) =SAMPLS ( I ) +4096+1 



16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 



C — WAIT FOR ACCESS TO STATUS COMMON BLOCK FOR UPDATE 
C — THEN CONVERT SAMPLES TO ENGINEERING UNITS AND STORE 

CALL LOCK{0) 

ANDATA(1)=FL0AT (SAMPLS (1) ) 

ANDATA ( 2) =A LOG10( FLOAT (SAMPLS) *2. 34) -365. 98 
. ANDATA(3)=ALOG10(FLOAT(SAMPLS(3)/13.9)-21.5? 
ANDATA(4)=13.23*FLOAT(SAMPLS(4) )-2P.78 
ANDATAf5)=FL0AT (SAMPLS (5) ) 
ANDATA(6)=FL0AT (SAMPLS (6 )") /I 4 . 225 
ANDATA (7) =FLOAT (SAMPLS (7) ) 

ANDATA (8) =ALOG (FLOAT (SAMPLS (8 ) /23 . 98 ) +23 5 . 98 
ANDATA (9) =FLOAT (SAMPLS (9) ) 
ANDATA ( 10 ) =FLOAT ( SAMPLS ( 1 ) ) 

ANDATA(11)= (FLOAT (SAMPLS (11) ) -1 1 9 . 34 ) /5 . 734 
CALL INPUT(#0E8H,DIGDAT) 
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RELEASE LOCK ON STATUS COMMON BLOCK 
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32 



CALL UNLOCK (P) 

C-- DELAY FOR 1 SECOND THEN SCAN AGAIN 

CALL WAIT 

LOOP BACK 

GOTO IP 
END 
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ANALOG$IO$MOD: 
DO; 



*********************** 



Inputs analog samples into buffer provided as 
calling parameter. 



*********** 



********/ 
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DECLARE AN$RESP (10) BYTE PUBLIC- 
DECLARE ANALOG$REQUEST$MESSAGE aiSmsg; 

INITIO: PROCEDURE PUBLIC; 

/* initializes mesage to be used for analog samples */ 

ANALOGSREQUESTSMESSAGE. length=size ( ANALOG$REQUEST$MESSAGE) ; 
ANALOG $REQUESTSMESSAGE.type=AISQS; 

ANALOG$REOUEST$MESSAGE.response$exchange=.AN$RESP; 
ANALOG SREQUEST$MESSAGE.base$ptr=0FFF0H; 
ANALOGSREQUESTSMESSAGE. channel $gain=0; 

RETURN; 

END; /* of INITSIO */ 

SMPLSIN: PROCEDURE(sample$buffer$ptr,buf$size) PUBLIC; 

/* inputs buf$size/2 analog word samples */ 

DECLARE (sample$buffer$ptr,buf$size, dummy) ADDRESS; 
DECLARE sampleSbuffer BASED sample$buffer$ptr (1) BYTE; 

ANALOG$REQUEST$MESSAGE.array$ptr=sample$buffer$ptr; 
ANAL0G?RECUEST$MESSAGE.count=buf$size/2; 

CALL ROSEND(.RQAIEX, .ANALOG $REQUEST$MESSAGE) ; 
dummy=RQWAITf .AN$RESP,0) ; 
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42 



RETURNS- 
END; /* of SMPLSIN */ 



END ANALOG SI 0$MOD; 
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SUBROUTINE SCAN 
C 

C— CODE FOR SCAN TASK THAT COMPARES STATUS VALUES WITH 
C — SETPOINTS AND SETS OPERATOR ALARMS ACCORDINGLY. ALSO 
C— LOGS DISK RECORD OF STATUS WHEN MIN5UP FLAG IS TRUE. 
C 
$INCLIJDE ( : Fl : EQUIV. DEC) 

I^CHARACTER BUFFER*57, PARAMS (57) *1 

REAL PH , VOLUME , TEMP, DI SOXY , TOTCAR , ORGCAR 

REAL SUSSOL,PHOSFT, INFLOW, EFLFLO, TURBID 

INTEGER*! DIGDAT 

INTEGER* 2 MONTH,DAY, YEAR, HOUR, MINUTE, SECOND 

EQUIVALENCE (PARAMS, BUFFER) 

EQUIVALENCE ( PARAMS, PH) 

EQUIVALENCE (PARAMS (5) , VOLUME) 

EQUIVALENCE (PARAMS (9) , TEMP) 

EQUIVALENCE (PARAMS (13) ,DISOXY) 

EQUIVALENCE (PARAMS (17) ,TOTCAR) 

EQUIVALENCE (PARAMS (21 ), ORGCAR) 

EQUIVALENCE (PARAMS (25) ,SUSSOL) 

EQUIVALENCE (PARAMS (29) ,PHOSFT) 

EQUIVALENCE (PARAMS (33) , INFLOW) 

EQUIVALENCE (PARAMS (37) ,EFLFLO) 

EQUIVALENCE (PARAMS (41 ), TURBID) 

EQUIVALENCE (PARAMS (4 5) , DIGDAT) 

EQUIVALENCE (PARAMS (46) ,MONTH) 

EQUIVALENCE (PARAMS (48 ), DAY) 

EQUIVALENCE (PARAMS (50 ), YEAR) 

EQUIVALENCE (PARAMS (52) , HOUR) 

EQUIVALENCE (PARAMS (54 ), MINUTE) 

EQUIVALENCE (PARAMS (56) , SECOND) 

INTEGER*2 ERRFLG, REGNO, DUMMY 

REAL SETSOL,SETCAR,SETPHS,SETTRB 

INTEGER*! MIN5UP 

COMMON /MIN5/ MIN5UP 

COMMON /SETPNT/ SETPHS,SETSOL,SETCAR,SETTRB 

k COMMON /STATUS/ BUFFER 
COMMON /LSTREC/ REGNO 

INITIALIZE RECORD COUNTER 



® 



C 

c— 

c 

10 



RECN0=1 



INITIALIZE MATH LIBRARIES 



DUMMY=0 

CALL FQFSET (DUMMY, DUMMY) 



WAIT FOR ACCESS TO STATUS AND SETPOINT COMMON BLOCKS 
CALL LOCK(0) 
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CALL LOCK(l) 
C 
C~ SCAN FOR ALARMS ONLY IF EFFLUENT PUMP IS ON 

IF( (DIGDAT. AND. #04H) .EQ.#04H) THEN 

IF(PHOSFT.GT.SETPHS) THEN 

CALL OUTPUT(#0EBH,#01H) 

ELSE 

CALL OUTPUT(#0EBH,#00H) 

ENDIF 

IF(SUSSOL.GT.SETSOL) THEN 

CALL OUTPUT(#0EBH,#03H) 

ELSE 

CALL OUTPUT(#0EBH,#02H) 

ENDIF 

IF (TOTCAR. GT.SETCAR) THEN 

CALL OUTPUT(#0EBH,#05H) 

ELSE 



® 
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58 
59 
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6 3 
64 

6 5 
6 6 
67 
68 
69 



70 
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CALL OUTPUT(#0EBH,#04H) 

ENDIF 

IF(TURBID.GT.SETTRB) THEN 

CALL OUTPUT(#0EBH,#(17H) 

ELSE 

CALL OUTPUT(#0EBH,#06H) 

ENDIF 

ENDIF 

IF MIN5 TASK HAS SET MIN5UP LOG STATUS ON DISK 

IF{MIN5UP.NE.0) THEN 
MIN5UP=0 

WAIT FOR ACCESS TO DISK 

^^ 

CALL L0CK{2) 

OPEN ( 3 , FI LE= ' : D0 : TODAYS . RPT ' , STATUS= ' OLD ' , IOSTAT=ERRFLG , 
JERR=900 0,ACCESS='DIRECT' ,RECL=57) 
WRITE(3,REC=RECNO,IOSTAT=ERRFLG,ERR=9100) BUFFER 
RECN0=RECN0+1 

CLOSE (3,IOSTAT=ERRFLG,ERR=9200) 
CALL UNLOCK (2) 
ENDIF 



C — RELEASE LOCK ON STATUS AND SETPOINT COMMON BLOCKS 



CALL UNLOCK(l) 
CALL UNLOCK (0) 



DELAY FOR 1 SECOND THEN SCAN AGAIN 

CALL WAIT 
LOOP BACK 

GOTO 10 
ERROR HANDLERS 
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C 

r9000 


WRITE{6 


9001) 


ERRFLG 


75 


9001 


FORMAT ( 


OPEN 


3RR0R IN SCAN; 


76 




GOTO*10 






77 


9100 


WRITE(6 


9101) 


ERRFLG 


78 


9101 


FORMAT ( 


WRITE 


ERROR IN SCAN 


79 




GOTO 10 






80 


9200 


WRITE(6 


9201) 


ERRFLG 


81 


9201 


FORMAT ( 


CLOSE 


ERROR IN SCAN 


82 


^\ 


GOTO 10 






83 




END 
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MIN$5$M0D: 
DO; 

This module contains the code f.or TIMER$5 who 
waits for 5 minutes and sets a flag telling 
SCAN to log a report on the disk, and for 
WAIT who waits for 1 second then returns 



******** 



********** 
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$nol ist 

DECLARE min$5$ex (10) BYTE PUBLIC; 
DECLARE min$5$up BYTE AT(0FFEEH); 
DECLARE time$out$msg$ptr ADDRESS; 
DECLARE f ive$minute$delay$count LITERALLY 
DECLARE timesSup LITERALLY '01H'; 



WAIT: PROCEDURE REENTRANT PUBLIC; 
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timeSout$msg$ptr=RQWAIT (.min$5$ex,20); 
RETURN; 
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END; 

TIMERS: PROCEDURE PUBLIC; 
min$5$up=0; 

/* enter task ]oop */ 

DO WHILE 1; 

time$out$insg$ptr=R0WAIT(.min$5$ex,f iveSminuteSdelayScount) ; 

min$5$up=times$up; 

END; /* of do while ] */ 
END; /* of procedure */ 
END; /* of module */ 
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REPORT: 
DO; 



************** 



This module contains the code for the REPORT 
task that prints formatted reports of system 
status upon command. Commands come in from 
PRTREQ exchange with type=100 for todays 
status report and type = 101 for yesterday's 
status report. PRINT is the FORTRAN routine 
that does the actual work. 

*********************************1,**********-l,***1H,1,*i,*1,1,*1,*1, 

$nolist 

PRINT: PROCEDURE (f i le$ptr ,name$si ze , request$type) EXTERNAL; 

DECLARE (f ile$ptr,name$size) ADDRESS; 

DECLARE requestStype BYTE; 
END PRINT; 

FOFSET: PROCEDURE (A, ERRH) EXTERNAL; 
DECLARE (A, ERRH) ADDRESS; 
END FQFSET; 

DECLARE prtSreq (10) BYTE PUBLIC; 

REPORT: PROCEDURE PUBLIC; 

DECLARE todayStype LITERALLY '100'; 
DECLARE yesterdayStype LITERALLY '101'; 
DECLARE (ptr, dummy) ADDRESS; 
DECLARE msg BASED ptr STRUCTURE ( 

link ADDRESS, 

length ADDRESS, 

type BYTE, 

homeSexchange ADDRESS, 

response$exchange ADDRESS) ; 

34 2 DECLARE today$f i le$name (*) BYTE DATA (': DE : TODAYS . RPT ') ; 

35 2 DECLARE ystday$f i leSname (*) BYTE DATA( ' : D0: YSTDAY. RPT ' ) ; 

/* initialize math handler */ 



21 


1 


22 


2 


23 


2 


24 


2 


25 


1 


26 


2 


27 


2 



30 


2 


31 


2 


32 


2 


33 


2 



36 2 dummy=0; 

37 2 CALL FQFSET (.dummy, .dummy) ; 

./* enter task loop */ 

^® ^ /^P\ °° WHILE 1; 

39 3 ry) ptr=RQWAIT(.prt$req,0); 



40 


3 


41 


3 


42 


3 


43 


3 


45 


3 


46 


2 


47 


1 



IF msg.type=today$type THEN 

CALL print(.today$file$name,SIZE(today$f ileSname) ,.msg,t 
ype ) ; 

ELSE IF msg.type=yesterday$type THEN 

CALL print(.ystday$f ile$name,size(ystday$f ileSname) , .msg 
•type); 

CALL RQSEND(msg.response$exchange,ptr) ; 
END; /* of do while */ 
END; /* of task */ 
END REPORT; 
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ISIS-II FORTRAN-80 COMPILATION OF PROGRAM UNIT HEADER 

OBJECT MODULE PLACED IN : Fl : PRNTMD. OBJ 

COMPILER INVOKED BY: FORT80 : Fl : PRNTMD. FRT DEBUG DATE ( 1 0/1 2/78 ) PAGEWIDTH(78 



1 SUBROUTINE HEADER 
C 

C — CALLED BY PRINT TO OUTPUT REPORT HEADER 
C 

2 WRITE(6,200) 

3 200 FORMAT (• DATE TIME PH VOLUME TEMP DISSOLVED 

1 'TOTAL 'organic SUSPENDED PHOSPHATE INFLUENT EFFLUENT ', . 
2'TURBID AIR DIS MIX INF') 

4 WRITE(6,201) 

5 201 FORMAT(44X, 'OXYGEN CARBON CARBON SOLIDS C0NC',6X, 

I'FLOW FLOW) 

6 WRITE(6,202) 

7 202 FORMAT(24X, ' (CU.M) (C) (MG/ML) (MG/ML) (MG/ML) 

l'(MG/ML) (MG/ML) (MG/ML) (MG/ML) %') 

8 RETURN 

9 END 



ISIS-II FORTRAN-00 COMPILATION OF PROGRAM UNIT PRINT 

OBJECT MODULE PLACED IN ; F 1 : PRNTMD. OBJ 

COMPILER INVOKED BY: FORTO0 : Fl : PRNTMD. FRT DEBUG DATE ( 10/1 2/78 ) PAGEWIDTH (78 ) 



C — SUBROUTINE PRINT CALLED BY REPORT TO GENERATE FORMATTED 

C — REPORTS. PRINTS EITHER TODAY'S FILE OR YESTERDAY'S 

C — DEPENDING ON FILNM INPUT VALUE.. 
C 

1 SUBROUTINE PRINT ( FILNM , TYPE ) 

2 IMPLICIT LOGICAL (A-Z) 

3 CHARACTER*14 FILNM 

A INTEGER*2 ERRFLG , RECCNT, LSTREC 

5 INTEGER*1 TYPE 

6 INTEGER*1 INDEX 

7 $INCLUDE(:F1:E0UIV.DEC) 

8 = CHARACTER BUFFER* 5 7 , PARAMS ( 57 ) * 1 

9 = REAL PH, VOLUME, TEMP, DISOXY,TOTCAR,ORGCAR 
IB = REAL SUSSOL,PHOSFT, INFLOW, EFLFLO, TURBID 

11 = INTEGER*1 DIGDAT 

12 = INTEGER*2 MONTH , DAY , YEAR, HOUR , MINUTE , SECOND 

13 = EQUIVALENCE (PARAMS , BUFFER) 

14 = EQUIVALENCE (PARAMS, PH) 

15 = EQUIVALENCE (PARAMS ( 5 ), VOLUME ) 

16 = EQUIVALENCE ( PARAMS (9 ), TEMP) 

17 = EQUIVALENCE (PARAMS ( 1 3) , DISOXY ) 

18 = EQUIVALENCE (PARAMS ( 17 ) ,TOTCAR) 

19 = EQUIVALENCE (PARAMS ( 2 1 ), ORGCAR) 

20 = EQUIVALENCE (PARAMS ( 25 ), SUSSOL) 

21 = EQUIVALENCE (PARAMS ( 29 ), PHOSFT) 

22 = EQUIVALENCE (PARAMS ( 33 ), INFLOW) 

23 = EQUIVALENCE (PARAMS ( 37 ), EFLF LO) 

24 = EQUIVALENCE (PARAMS (4 1 ), TURBID) 

25 = EQUIVALENCE (PARAMS (4 5) , DIGDAT) 

26 = EQUIVALENCE (PARAMS (46 ), MONTH) 

27 = EQUIVALENCE (PARAMS ( 4 8 ), DAY) 

28 = EQUIVALENCE (PARAMS (50 ), YEAR) 

29 = EQUIVALENCE ( PARAMS (52) , HOUR) 

30 = EQUIVALENCE (PARAMS (54 ), MINUTE) 

31 = EQUIVALENCE ( PARAMS ( 55 ), SECOND) 

32 CHARACTER*3 AIR, MIX, INFLNT, DISCHG 
3 3 COMMON /LSTREC/ LSTREC 

C 

C-- INITIALIZE RECORD COUNT 

C 



C-- INITIALIZE INDEX 
C 



C-- OUTPUT HE/VDER 
C 

CALL HEADER 
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WAIT FOR FILE ACCESS IF TODAY'S FILE 



40 
41 
42 
43 
44 
45 






tl® 



50 
51 
52 
53 
54 
55 
56 
57 
58 
59 
60 
61 



IF(TYPE.EQ.100) CALL L0CKf2) 

0PEN(8,FILE=FILNM,STATUS='0LD' , IOSTAT=ERRFLG , 
1ERR=9000,ACCESS=' DIRECT ',RECL=57) 

READ(8,REC=RECCNT,IOSTAT=ERRFLG,ERR=9100) BUFFER 

RECCNT=RECCNT+1 
^IF( (DIGDAT.AND.#01H) .EQ.#01H) THEN 

AIR=' ON' 

ELSE 

AIR='OFF' 

ENDIF 

IF( (DIGDAT.AND.#02H) .EQ.#02H) THEN 

MIX=' ON' 

ELSE 

MIX='OFF' 

ENDIF 

IF( (DIGDAT.AND.#04H) .EQ.*04H) THEN 

DISCHG=' ON' 

ELSE 

DISCHG='OFF' 

ENDIF 

IF( (DIGDAT.AND.#08H) .EC.#08H) THEN 

INFLNT=' ON' 

ELSE 

inflnt='off' 
Sendif 
write(6, 101) month, day, year, hour, minute, second, 

IPH, VOLUME, TEMP, DISOXY,TOTCAR,ORGCAR,SUSSOL,PHOSFT, 
2INFL0W,EFLFL0,TURBID,AIR,DISCHG,MIX,INFLNT 

FORMAT (12, '/',I2,V',I2,1X,I2,':',I2,':',I2,1X,F4.1,1X,F9.2, 
Z1X,F9.4,1X,F9.4,1X,F8.3,1X,F8.3,1X,F9.4,1X,F9.4,IX,F8.3,1X,F8.3 

-,1X,F7.3, 
Z1X,A3,1X,A3,1X,A3,1X,A3) 



C— CHECK FOR END OF FILE AND OTHER THINGS 



63 
64 
65 
66 
67 
68 
69 
70 
71 
72 
73 
74 
75 
76 
77 
78 
79 
80 
81 
82 



® 



^INDEX=INDEX+1 

IF(TYPE.EQ.100) THEN 

IF(INDEX.LE.10) THEN 

IF(RECCNT.LT.LSTREC) THEN 

GOTO 10 

ELSE 

CLOSE (8 , IOSTAT=ERRFLG , ERR=9200 ) 

CALL UNLOCK (2) 

RETURN 

ENDIF 

ELSE 

INDEX=1 

CLOSE (8 , IOSTAT=ERRFLG, ERR=9200) 

CALL UNLOCK (2) 

GOTO 1 

ENDIF 

ELSE 

IF(RECCNT.LE.288) THEN 

GOTO 10 

Velse 



8 3 




84 




85 




86 






C 




C — 




C 


87 


9000 


88 


9001 


89 




90 


9100 


91 


91P1 


92 




9 3 


9200 


94 


9201 


95 




96 





CLOSE{8,IOSTAT=ERRFLG,ERR=920 0) 

RETURN 

ENDIF 

ENDIF 

ERROR HANDLERS 

WRITE(6,9P01) ERRFLG 

FORMAT('OPEN ERROR IN PRINT; #',I4) 

RETURN 

WRITE(6,9101) ERRFLG 

FORMAT ('READ ERROR IN PRINT; #', 14) 

RETURN 

WRITE(6,9201) ERRFLG 

FORMAT ( 'CLOSE ERROR IN PRINT; #',I4) 

RETURN 

END 
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PL/M-80 COMPILER 



10/12/78 PAGE 



ISIS-II PL/M-80 V3.1 COMPILATION OF MODULE INITMD 

OBJECT MODULE PLACED IN : Fl : INITMD. OBJ 

COMPILER INVOKED BY: plm80 : Fl : INITMD. plm DEBUG DATE ( 10/12/78) PAGEWIDTH (78) 



INITMD: 
DO; 



]7 


1 
2 


18 
19 


I 
1 


2P 
21 

22 


1 


2 3 
24 
25 


I® 



FQPGO: PROCEDURE EXTERNAL; 
END FQ0GO; 

DECLARE semaphore (3) ADDRESS EXTERNAL; 
DECLARE token (3) STRUCTURE ( 
msgShdr) EXTERNAL; 

INIT: PROCEDURE PUBLIC; 
DECLARE i BYTE; 

CALL FQ0GO; 

/* initialize semaphores */ 

DO i=0 TO 2; 

CALL RQGEND( semaphore (i),.token(i)); 

END; 



/ 



^® 



PROGRAM THE 8255 */ 
OUTPUT (0EBH)=92H; 
/* TURN OFF ALL ALARMS */ 
OUTPUT (0EAH)=0; 



28 


2 


RETURN; 


29 


2 


END; 


3r 


1 


END INITMD; 



ASM80.OV3 :F1:X2CFG.M80 DEBUG PAGEWIDTH (78) 
ISIS-II 8080/8085 MACRO ASSEMBLER, V2.e 



X2CFG PAGE 1 



LCC OBJ 



0000 200? 



0000 
0000 



SEQ 

] 

2 

3 

4 

5 

360 

361 

362 

363 

364 

365 

366 

357 

368 

3 69 
426 

4 83 
540 
597 
654 
711 
76 8 
769 
882 
939 
996 

10 53 
1110 
1167 
1224 
1281 
1282 
1283 
1284 
1288 
1289 
1290 
1291 
1295 



SOURCE STATEMENT 



NAME 
CSEG 
PUBLIC 

RQRATE: DW 

$NOLIST 

SLIST 

$NOGEN 

ntask set 
nexch set 

NDEV SET 
NCONT SET 



® 



RQRATE 
32 



BUILD INITIAL TASK TABLE 

STD RQADBG,6 4,129,RQWAKE 

STD RQTHDI,36,112,RQOUTX 

STD R0PDSK,48,129,R0DSKX 

STD RQPDIR,48,130,RQDIRX 

STD RQPDEL,64,131,RQDELX 

STD RQPRNM,6 4,13 2,R0RNMX 

STD RQAIH,34,133,RQAIEX 

EXTRN RQHDl 

CONSTD CNTR0L,RQHD1, 80,CNSTK, 81,C0NTEX 

STD TIMER, 64, 20,0 

STD TIMUPD, 64, 140,0 

STD TIMERS, 64, 141,0 

STD STSINP, 64, 142,0 

STD CHANGE, 64, 143,0 

STD REPORT, 800, 144,0,18 

STD SCAN, 800, 144, 0,18 

ALLOCATE TASK DESCRIPTORS 

GENTD 

ALLOCATE EXCHANGES 



XCH 
XCH 



CONTEX 
FQ0LOK 
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1299 


V.-:7 iNTXCH 


RQL5EX 


1305 ; 






13 06 ; 


BUILD INITIAL 


1307 ; 






13 08 


XCHADR 


RQDSKX 


1315 


XCHADR 


RQDIRX 


1322 


XCHADR 


RQRNMX 


1329 


XCHADR 


RQDELX 


1336 


XCHADR 


RQAIEX 


1343 


PUBXCH 


CONTEX 


1350 


/C^ PUBXCH 
^V^ PUBXCH 


RQL5EX 


1357 


FQ0LOK 


1364 


^-^ XCHADR 


RQINPX 



SEQ 

1371 
1378 
1385 
1392 
1399 
1406 
1413 
1420 
1427 
1434 
1441 
1448 
1455 
1462 
1469 
1476 
1483 
1490 
1491 
1492 
1493 
1500 
1501 
1502 
1503 
1544 
1585 
1586 
1587 
1588 
1604 
1605 
1606 
1607 
1627 



SOURCE STATEMENT 



XCHADR 


RQOUTX 


XCHADR 


RQDBUG 


XCHADR 


RQWAKE 


XCHADR 


RQALRM 


XCHADR 


RQL6EX 


XCHADR 


R0L7EX 


XCHADR 


STSLOK 


XCHADR 


SETLOK 


XCHADR 


DSKLOK 


XCHADR 


BMPTIM 


XCHADR 


TIMPOL 


XCHADR 


PRTREQ 


XCHADR 


CHRESP 


XCHADR 


ANRESP 


XCHADR 


MIN5EX 


XCHADR 


TIMEEX 


XCHADR 


RDRESP 


BUILD CREATE TABLE 


CRTAB 




BUILD DEVICE CONFK 


DCT 


D0, 0,0,0 


DCT 


Dl, 0,0,1 



BUILD CONTROLLER SPECIFICATION TABLE 

CST 0,80H, 5, RQL5EX, CONTEX 

BUILD BUFFER ALLOCATION BLOCK 

BAB 3,BUFP0L 
END 



PL/M-80 COMPILER 



10/12/78 PAGE 1 



ISIS-II PL/M-80 V3.1 COMPILATION OF MODULE CAMMOD 

OBJECT MODULE PLACED IN :F1:CAM.0BJ 

COMPILER INVOKED BY: plm80 :Fl:CAM.plm DEBUG DATE (10/12/78) PAGEWIDTH (78) 



CAMMOD: 
DO; 

/* CONTROLLER TASK STACK */ 

DECLARE CN$STK (80) BYTE PUBLIC; 

/* DFS INTERNAL BUFFER SPACE */ 

DECLARE RQDBUF (700) BYTE PUBLIC; 

/* DFS STATIC BUFFER POOL */ 

DECLARE BUF$POL (1200) BYTE PUBLIC; 

„^END CAMMOD; 
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Single-board microcomputers offer fiardware cost-effectiveness for 
implementing many real-time systems. A compatible, resident, real- 
time executive program provides savings in software development 



An Integral Real-Time Executive 
For Microcomputers 

Kenneth Burgett and Edward F. O'Neil 

Intel Corporation 
Santa Clara, California 



Single-board computers, or microcomputers, that contain 
central processor, read- write and programmable read- 
only memory, real-time clock, interrupts, and serial and 
parallel input/output all on one printed circuit board, 
have made feasible a whole spectrum of applications 
which previously could not be economically justified. 
These microcomputers have also opened up a range of 
applications where the high functional density of large- 
scale integration provides advantages over previous solu- 
tions such as hardwired logic or relatively expensive 
minicomputers. While microcomputers readily solve hard- 
ware requirements, software for single-board computer 
applications with real-time characteristics (which are 
in the majority) has until now been generated individu- 
ally for each application. 

The Intel RMX/80* Real-Time Multi-Tasking Execu- 
tive simplifies real-time application software development, 
and at the same time furnishes capabilities optimized for 
the microcomputer environment. It provides the means to 
concurrently monitor and control multiple external events 
that occur asynchronously in real-time. The program 
framework allows system builders to immediately imple- 
ment software for their particular applications, and to 
avoid specific details of system interaction. 

Major functions of the executive include system re- 
source access based on task priority, intertask communi- 
cation, interrupt driven device control, real-time clock 
control, and interrupt handling. In combination, these 
functions eliminate the need to implement detailed real- 
time coordination for specific applications. 

Previously, two alternative software approaches were 
used to solve microcomputer applications. First, many 



designers created their own operating executive, indi- 
vidually tailored for each application. Obviously, this 
approach was expensive and time-consuming. The second 
approach was to use a minicomputer executive which had 
been adapted to a microcomputer. Since this software 
was designed for a different processing environment and 
then "stripped down," it suffered from major inad- 
equacies when executed on microcomputers. The alterna- 
tive, RMX/80, has been designed specifically to provide 
a general-purpose real-time executive tailored to Intel 
SBC 80 and System 80 microcomputers. 



Real-Time System Requirements 

All software design approaches for use in real-time ap- 
plications include capability for concurrence, priority, 
and synchronization/communication. 

Concurrence — Real-time systems monitor and control 
events which are occurring asynchronously in the physi- 
cal world. Microcomputer software does not know ex- 
actly when external events will occur; however, it must 
be prepared to perform the necessary processing upon 
demand, whenever the events actually do occur. Typical- 
ly, interrupts are used to inform the microcomputer that 
an event has occurred. At interrupt time, system control 
software determines what processing to perform, as well 
as the relative sequence in which processing must take 
place. 



*HMX/80'''" is a registered trademark of the Intel Corp, Santa 
Clara. Calif. 
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Programs related to external events are processed in 
an interleaved manner based on interrupt occurrence 
and priority. For instance, one routine is executing when 
an interrupt activates, signaling that a higher priority 
event has occurred. At this point, the routine related to 
the priority interrupt is started, while execution of the 
less important routine is discontinued temporarily. When 
the more important routine is completed, or temporarily 
halted for some other reason, execution of the less im- 
portant routine is resumed. In this manner, multiple pro- 
grams execute concurrently in an interleaved fashion. 
Priority — In a real-time environment, certain events re- 
quire more immediate attention than others because of 
their significance within the physical world. Immediacy 
is relative to other processing, and is determined by ap- 
plication requirements. The concept of immediacy or pri- 
ority, however, is common throughout all real-time micro- 
computer applications. In priority-based systems, the most 
important program (one that is not waiting for some 
physical or logical reason) is the one executing. 

A classic illustration of program priority in real-time 
systems is found in the area of plant control. When the 
plant begins to fail in a nonrecoverable manner, it is 
imperative that the plant be shut down as quickly as 
possible. For this reason, shutdown processing takes 
priority over all other system demands. Software pri- 
ority enforces this hardware concept of physical opera- 
tional events. 

Synchronization /Communication — Another common sim- 
ilarity in most real-time systems is the need for synchro- 
nization between various events in the physical world 
which are under microcomputer control. Synchroniza- 
tion is defined as the process whereby one event may 
cause one or more other events to occur. Communication 
is the process through which data are sent between in- 
put/output (I/O) devices or programs and other pro- 
grams within the microcomputer system. 

An example of the need for synchronization and com- 
munication is a microcomputer system for weighing and 
stamping packages. One part of the system weighs the 
package, calculates pricing, and releases the package 
onto a conveyor belt. Price and weight data are com- 
municated to another part of the system which stamps 
the data onto the package after it arrives at a sensor 
station. Synchronization is demonstrated by the occur- 
rence of one event — package arrival-— causing another 
event — package stamping — to occur. 

Compatible Benefits 

To satisfy real-time microcomputer software require- 
ments, the RMX/80 Real-Time Executive software (Fig 
1) was designed. This program differs from existing 
software systems by offering capabilities directly re- 
lated to the single-board microcomputer environment 
in which it operates. These capabilities have two major 
bottom-line benefits compared with equivalent minicom- 
puter systems. First, the executive code is compact 
enough to allow a large number of real-time applications 
to be processed on a single microcomputer board. To 
accomplish this capability, its nucleus is optimized to 
reside in less than 2k bytes [ie, in a single 16k program- 
mable read-only memory (p/ROM) ], thereby allowing up 
to lOK of onboard memory for application-related soft- 
ware and storage. 




Fig 1 A typical RMX/80 system. Mul- 
tiple tasks control a given application. 
Nucleus controls execution of both 
user and executive tasks through 
task-to-task comnnunication, real-time 
clock, priority resolution, and inter- 
rupt handling facilities. All tasks with- 
in an RMX/80-based application use 
at least some of these capabilities; 
other optional executive tasks include 
debugger, free-space manager, and 
device control for operator's console, 
diskette file system, analog subsys- 
tems, and high speed mathematics 
unit 



Second, the executive may be p/ROM -resident. When 
the microcomputer system is po.wered on, the software 
system (executive plus application programs) is auto- 
matically initialized and begins execution of the highest 
priority application task. Typical major real-time execu- 
tives, however, are totally random-access read-write semi- 
conductor memory (RAM) -resident, which means they 
must be initialized (booted) from a peripheral device, 
such as diskette, cassette, or communications line, into 
microcomputer memory. The need for peripheral devices 
significantly increases the total cost of traditional real- 
time executive-based solutions. 



Sample Application 

Functioning as a real-time executive for microcomputers, 
this software system provides facilities for orderly con- 
trol and monitoring of asynchronously occurring ex- 
ternal events. Although these events may differ widely 
from application to application, facilities are adaptable 
to nearly all processes where the microcomputers are 
used, including process and machine control, test and 
measurement, data communications, and specialized on- 
line data processing applications (where one or more 
terminals access diskette-based data). The executive is 
particularly useful in dedicated low cost applications 
which were not economically feasible before the advent 
of microcomputers. For example, consider the require- 
ment of gas pump control in a service station (Fig 2). 
In this station, a microcomputer system operating 
with RMX/80 concurrently monitors and controls mul- 
tiple gas pumps, and sends price and volume informa- 
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tion to one central location. At the same time, informa- 
tion about station operation is being transmitted over a 
communications line to a regional computer. 

Individual tasks are developed independently to mea- 
sure gas flow, calculate and display price information, 
transfer data to the central computer, and monitor levels 
of gasoline in underground storage. All this processing 
takes place concurrently under program control. (Credit 
verification, charge slip printing, and billing can also 
be controlled by additional software tasks.) 

Efficient gas station operation demands that the hard- 
ware/software system be highly reliable. The compatible 
benefits of compact code, p/ROM residency, and self- 
initialization on a single-board microcomputer system all 
combine to ensure functional integrity. 

Software Structure 

RMX/80 simplifies the effort for developing a real-time 
system, first, by providing many commonly required 
software functions. Second, its software structure pro- 
motes efficient program development. Programmers who 
are familiar with structured programming will find task 
orientation both natural and easy to use. 

Tasking means that a larger program is divided into 
a number of smaller, logically independent programs or 
tasks. The key is to identify functions that may occur 
concurrently. For example, consider the tasks required 
for a terminal handler — real-time asynchronous I/O be- 
tween an operator's CRT terminal and the executive. 

Input Handler Task — One task must be ready to accept 
a data character from the terminal at any time. This is 
done by responding to an interrupt signal from the 
terminal and then accepting the data character. The task 
immediately passes the input character to a subsequent 
task automatically and then goes back to wait for an- 
other interrupt. 

Line Buffer Task — As characters are received from the 
input handler they must be placed into a buffer to form 
a line. Eventually, the buffer will be filled or the logical 
end-of-line will be signaled by a carriage return char- 
acter. At this point, the line buffer must be sent to some 
other task for processing. 

Echo Driver Task — For a full-duplex terminal, it is 
necessary to return each input character to the terminal 
for display on the CRT screen. This task waits for a 
character, which could be sent by either the line buffer 
or input handler task, and then sends the character to 
the terminal. It then waits for the next character. 

Note that input handler and echo driver are described 
as waiting for an event. Within the RMX/80, that is 
literally the case. While they wait, however, system re- 
sources are available for other tasks, such as that of the 
line buffer. Thus, effective processing may occur con- 
currently with necessary waiting periods. Notice also 
that a number of other tasks may also be active within 
the system. In fact, the greater the number of tasks run- 
ning concurrently, the more effectively system resources 
are used. Concurrent operation eliminates many time 
wasting procedures from a real-time system. For ex- 
ample, the executive can eliminate the need for many 
timing loops where the processor simply executes a no- 
operation instruction repeatedly while waiting for an 
event to occur. 




TO REGIONAL 
COMPUTER VIA 
TELEPHONE LINES 



Fig 2 Microcomputer control for gas pump automa- 
tion. In this example, executive-based system simul- 
taneously controls two pumps, displays information on 
operator's console, and communicates with regional 
computer. At a given time, more or fewer functions 
could be operating concurrently. System expansion 
can be easily accomplished by adding tasks and 
modular hardware 



Within the executive, tasks not only are logically in- 
dependent, they are also physically independent, actually 
contending with each other for the use of the processor 
and other system resources. The executive resolves this 
contention based on the priority of each task. 

In the terminal handler example, it is clear that the 
input handler must have highest priority, since accept- 
able performance cannot tolerate the loss of data. Second 
highest priority is given to the echo driver, so that data 
appearing on the screen remain coordinated with the 
input. Lowest priority goes to the line buffer, since that 
function does not depend directly on an external asyn- 
chronous event. There are no particular real-time con- 
straints on the line buffer as long as the input char- 
acters are eventually processed. 

It is possible to write the entire terminal handler as 
a single large task instead of as several smaller tasks. 
However, consideration must be given other high priority 
tasks operating within the system which may not be 
able to gain control while a low priority portion of the 
terminal handler, such as the line buffer task, is execut- 
ing. Therefore, tasks assigned as high priority are gen- 
erally kept as short as possible. If the terminal handler 
were written as one large task, it could tie up the entire 
processing system for a relatively trivial function. 

Task States 

Two task states have been implied — running and wait- 
ing. A running task is always the task which currently 
has the highest priority and is not suspended or waiting. 
A waiting task remains in the wait state until it receives 
a message or an interrupt for which it is waiting or until 
a specified time period has passed. The wait period can 
be timed using the system clock. 

A running task may suspend itself on some other task 
in the system. A suspended task cannot begin execution 
again until some running task orders it to resume. As 
an example, a password routine might temporarily sus- 
pend the echo driver of the terminal handler so that the 
password is not displayed. (The password routine must 
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remove the password from the line buffer, or it will be 
displayed as soon as execution of the echo driver is 
resumed. ) 

A task may also be in the ready state. A ready task is 
one that would be running except that a task with higher 
priority temporarily controls the system resources. The 
executive maintains a list of all tasks that are ready to 
run. The next task to be run is always the task with 
the highest priority in the ready list. 

The running task relinquishes its control of the sys- 
tem by 

(1) Putting itself into a wait state 

(2) Suspending itself 

(3) Sending a message to a higher priority task, which 
if it has the highest current priority, becomes the run- 
ning task 

(4) Being preempted by an interrupt to a higher pri- 
ority task 

In the case of an interrupt, the executive saves the 
status (contents of registers, etc) of the interrupted task 
so that it will be restarted correctly. 



Message Exchanges 

Tasks communicate with each other by sending messages 
(Fig 3). The sending task constructs the message to be 
sent in RAM or uses a previously assembled message. 
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Consumer task performs ini- 
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Fig 6 Producer task flow. 
Producer processing flow is 
opposit^ to that of consumer 
task. Instead of passively re- 
acting to requests from other 
tasks, producer task issues re- 
quests to which other tasks 
must respond 



The sending task then issues a send command that posts 
the address of the message at an exchange. 

An exchange is simply a set of lists maintained by the 
executive. The first list contains the addresses of messages 
available at that exchange. The second list consists of a 
list of tasks that are waiting for messages at that ex- 
change. When a task enters a wait state, it specifies the 
exchange where it expects eventually to find a message. 
The task may wait indefinitely, or it may specify that it 
will only wait a specific period of time before resuming 
execution. 

Messages, together with the exchange mechanism, pro- 
vide for automatic intertask communication and also for 
task synchronization. For example, a message to a par- 
ticular task may specify that the task is to send a re- 
sponse to a certain exchange. Thus, the original task 
may request an acknowledgement response to its mes- 
sage, or it may specify that a message is to be sent to 
a third task. RMX/80 treats interrupts like messages, 
the only difference being that interrupts have their own 
set of exchanges. 

Note that the sending and receiving of messages classi- 
fies tasks into two types — ^message consumers and mes- 
sage producers. A consumer task waits for a message, 
performs an action based on the message, and then 
returns to the wait state until another message is re- 
ceived. A producer task initiates its function by sending 
a message to another task, waits for a response, and then 
sends another message. Figs 5 and 6 graphically illustrate 
the processing within these two tasks. The distinction be- 



tween consumer and producer tasks is relative since many 
tasks act as both consumer and producer. 



Executive Modules 

RMX/80 is supplied as a library of relocatable and link- 
able modules. These modules are added selectively as 
required when the user-supplied tasks are passed through 
the link program. Only modules actually requested by 
the application are linked in. For example, if the appli- 
cation program does not specify use of the free-space 
manager, that module is not linked into the system. 

One module, the nucleus, provides basic capabilities 
(concurrence, priority, and synchronization/communi- 
cation) found in all real-time systems. Additional, op- 
tional modules may be configured with user programs 
(tasks) to form a complete application software system. 
These modules include: 

Terminal handler — Providing real-time asynchronous 
I/O between an operator's terminal and tasks running 
under the RMX/80 executive, the handler offers a line- 
edit feature similar to that of isis-ll and an additional 
type-ahead facility, (isis-ll is the supervisory system 
used on the Intellec Development System.) 
Free-space manager — This module maintains a pool of 
free RAM and allocates memory out of the pool upon 
request from a task. In addition, the manager reclaims 
memory and returns it to the pool when it is no longer 
needed. 
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is then transferred to its target SBC 
80 system via programmed p/ROMs 
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Debugger — Designed specifically for debugging soft- 
ware running under the RMX/80 executive, the debugger 
is used by linking it to an application program or task. 
Thus, it can be run directly from the single-board com- 
puter's memory. In addition, an in-circuit emulator, 
such as ICE-80, can be used to load and execute the 
debugger, providing all resources of the Intellec de- 
velopment system to simplify debugging effort. 

Analog interface handlers — Consisting of RMX/80 tasks, 
these handlers provide real-time control for SBC 711, 
724, and 732 systems. 

Diskette file systems — Giving RMX/80 users diskette 
file management capabilities, the diskette driver allows 
users to load tasks into the system and to create, access, 
and delete files in a real-time environment without dis- 
rupting normal processing. All file formats are compatible 
with isis-ll for both single and double density systems. 

In addition to application program module or task 
requirements, the user also supplies a set of generation 
parameters. These parameters are a set of tables that 
inform the executive of the number of tasks and ex- 
changes in the system. Fig 7 illustrates the system gener- 
ation process. 



duces recurring costs because it requires a minimum of 
memory and does not require peripheral bootstrap load- 
ing devices. RMX/80 results in economical, shorter, and 
more flexible software development efforts when design- 
ing, building, and verifying real-time user applications. 
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Summary 

The significance of RMX/80 to software design parallels 
the significance of the single-board computer to hard- 
ware design. Microcomputers allow designers without ex- 
tensive experience in digital systems to bring computer 
processing power into their applications. Similarly, the 
executive relieves the hardware designer of much soft- 
ware design required for real-time applications. Designed 
to facilitate growth, since new software needed to support 
hardware expansions can be supported easily by the ad- 
dition of new tasks, this executive also substantially re- 
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Abstract — Sound engineering methodology, which has long been val- 
ued in hardware design, has been slower to develop in software design. 
This paper uses a case study of a small real-time system to discuss soft- 
ware design philosophies, with particuar emphasis on the abstract ma- 
chine view of systems. It demonstrates how the currently popular soft- 
ware design axioms of generality and modularity can be used to produce 
a software system that meets severe space constraints while remaining 
relatively portable across a family of microcomputers. These sorts of 
constraints have often been used to justify ad hoc design approaches in 
the past. The results of the project suggest that the use of such tech- 
niques actually make the meeting of many constraints easier than would 
a less organized approach. In addition, the reliability and maintainability 
of the resultant product is likely to be better. 

I. Introduction 

A PROCESSOR, as defined only by its hardware, is typi- 
cally not an adequate base upon which to build applica- 
tions software. Broad classes of applications can be ex- 
amined and found to share more than the hardware defined 
instruction set. To avoid the reengineering of this common func- 
tionahty, we would prefer to build such common parts once and 
thereafter treat this base software as though it were part of the 
machine. For example, a software system sometimes called an 
operating system, an executive, a nucleus, a kernel, or some 
similar term, is often supplied with a hardware product and can 
be viewed in exactly this way. In this paper, we examine a small- 
scale system to demonstrate this approach to bridging the gap 
between the hardware and the application. That is, we will view 
the software as a direct extension of the hardware — a view which 
may indicate future directions in microprocessor integration of 
function. 

This paper is meant as both a case study of a particular system 
design and as a suggestion of the proper approach to such design 
situations in general. We will first discuss the abstract machine 
view of computer systems and attempt to demonstrate that this is 
a useful philosophical approach for building systems. We will 
then apply this approach to the discussion of a system to coor- 
dinate programs performing real-time control functions— RMX- 
SO^'^ [18]. The emphasis of the paper will be on techniques and 
methodology rather than on the particular functionality of RMX. 
Special attention will be given to such issues as the use of 
modularity to enhance the adaptability of the system and the use 
of design generality to achieve global rather than local optimiza- 
tions. 

II. The Concept of Abstract Machine 

What is a computing "machine" or processing unit? We gen- 
erally identify a processing unit as a particular collection of hard- 
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ware components that implement the instruction set of the 
machine. This very physical definition of a computer dates from 
mechanical processors. Even with modern computers, before 
large-scale integration, it was easy to physically point at the proc- 
essing elements as distinct from memories, peripherals, and pro- 
grams. Continued integration of function has at least made this 
physical distinction more difficult with single chips subsuming 
processing, memory, and peripheral interface functions. Micro- 
programming (i.e., replacing hardwired instruction logic with a 
more elementary programmed processor) as an implementation 
strategy has logically blurred this distinction as well. That is, 
when the basic visible instruction set of a processor is itself imple- 
mented in terms of more primitive instructions it is more difficult 
to identify ''the machine." It is clear that this narrow physical 
definition of a processor is not adequate for current technology 
levels and is likely to become even less viable as the technology 
continues to develop. 

Actually we have been using alternative definitions of a proces- 
sor for some time. All of the theoretical work in finite state 
machines, for example, deals with conceptual processors. Like- 
wise applications programmers seldom really regard the machine 
they program as much more than collection of instructions found 
in a reference manual — the physical implementation of the 
machine is of little concern to them. Indeed, they may never come 
physically near the hardware if they deal with a typical time- 
sharing system — rather, the terminal is the only physical manifes- 
tation of the computer such users may see. 

More to point, perhaps, are the numerous interpreters that 
have been written for languages such as Basic. Each such inter- 
preter actually produces a conceptual machine with one instruc- 
tion set targetted to a specific application. With standard com- 
piled languages such as Fortran, Algol, or Pascal, a higher level 
source statement is translated into the instruction set of the 
physical hardware. In contrast, interpreted language systems 
translate the source into the instruction set of some conceptual 
machine that is better suited to the running of programs written in 
the language. For example, the hardware may not provide 
floating-point instructions or define a floating-point data repre- 
sentation. In such a case it may be easier to define a machine that 
recognizes a particular floating-point data format with an instruc- 
tion set that includes floating operations. These interpreters are 
high-level machines that have usually been implemented in soft- 
ware. Likewise, it should be readily apparent that, just as these in- 
terpreters provide high-level machines to their associated trans- 
lators, any programming language, compiled or interpreted, pro- 
vides one to its users. 

Interpreters of this sort typically may examine and decode a 
stream of instruction values in a manner analogous to the hard- 
ware. Alternately, the new instructions may all be executed as 
subroutine calls using the appropriate hardware instruction. That 
is, the entire bit pattern for call X (where X is the address of a 
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Fig. 1. Typical collection of abstract machines. 

routine that implements a part of the new instruction set) can be 
regarded as a new operation code rather than as the hardware 
operation call. In either case the programmer using these exten- 
sions can view the har ware-so ft ware combination as though it 
were a new machine with a more useful instruction set. Micropro- 
grammed machines such as the IBM 5100 or Burrough's 1700 
have simply optimized the performance of such interpreters or 
subroutine packages by committing them to a faster storage 
medium. 

Viewed in this Hght we can identify any collection of hardware 
and software that provide some well defined set of functions as 
defining an abstract machine [101, [12]. This machine has an in- 
struction set that consists of the functions provided by the hard- 
ware-software combination. For a particular application it may 
be possible to view multiple such abstract machines by taking 
various pieces of the whole. For example, the physical machine 
provided by a set of components is just one abstract machine. It is 
of particular interest since it is the greatest common abstract 
machine that can be identified as being used by any application 
running on that computer system. A Basic interpreter running on 
this machine might then constitute a second virtual machine. A 
Basic program running on this interpreter that accepted high level 
commands and performed according to them might be a third 
level machine usable by people with no knowledge of either the 
hardware or Basic. Whenever we can identify functions of suffi- 
cient commonality among a number of applications, it may be 
worth viewing the software which provides these functions as ex- 
tensions of the base hardware machine which define some aug- 
mented or even different machines. Users programming such an 
application can then view this abstract machine, rather than the 
base machine as the vehicle that they are programming, and in 
doing so avoid reengineering the functions that it provides. Fig. 1 
illustrates an example of such machines. It is important to remem- 
ber that at any time, many abstract machines may be thought of 
as existing on the same base hardware. 

III. Operating Systems as Abstract Machines 

The terms operating system or executive have been used to 
describe software systems of widely different functionality. These 
machines generally provide for the management of some machine 
resources such as input, output, memory space, memory access, 
or processor execution time. We might then attempt to define an 
operating system as some collection of software modules which 
defines an abstract machine that includes resource management 
functions as well as the hardware supplied computational func- 



tions [2], [6], [8], [11]. With such a broad definition, however, 
large-scale multi-user time-sharing systems and small single user 
microprocessor development systems both may claim to have 
operating systems. Clearly, the range of software systems covered 
by this definition is large, encompassing products which differ by 
orders of magnitude in complexity. Rather than become involved 
in trying to resolve this disparity, we will qualify our use of the 
term and refer to an operating system ** foundation." That is, we 
will describe a software system which provides a minimal base for 
the construction of real-time applications. We will avoid the 
somewhat irrelevant question of whether the system comprises a 
complete "operating system." 

The important item to reahze from the above discussion is that 
any operating system functionally enlarges the processor seen by 
the programmer, the functions that it provides become as much a 
part of the machine's functionality as jump instructions. Indeed, 
it is functionally unimportant to the user desiring to read from a 
file whether it requires a single hardware instruction or a large 
software routine to accomplish it. In terms of the abstract 
machine discussion above, we will examine a software package 
which defines an abstract machine that includes functions re- 
quired to coordinate programs performing real-time control ap- 
plications [1],[9],[12]. 

The key overall requirement of the operating sytem foundation 
that we discuss in this paper will be that it supply a minimal cover- 
ing set of functions to permit coordination of asynchronous 
tasks. To determine this set we will need to further examine the 
needs of its users and environment of its use. In describing this 
foundation, we are defining an abstract machine that must be 
programmed to be of lise; that is, like the instruction set of the 
base machine the foundation by itself performs no work but 
rather provides an environment within which useful tasks can be 
run. 

We should note, here, some of the limitations of the system 
which differentiate it from large-scale operating systems. First, it 
is not primarily intended for a multi-user environment, particu- 
larly because the underlying hardware does not provide the neces- 
sary support to protect users from one another. Also, it will often 
be used to control functions of specialized devices and therefore is 
"close" to the I/O devices. That is, it does not supply the sort of 
high level I/O control system which is often present in larger sys- 
tems for controlling more conventional I/O devices. Finally, it 
does not assume a backing store from which program overlays 
can be loaded (but it catt easily support such an extension). 



IV. Design Considerations 
A. Use Environment 

The foundation system we will describe is RMX-80 [5] which 
was designed to be used with members of Intel's Single Board 
Computer (SBC) family of products. This family includes a wide 
range of bus compatible processor, memory, and peripheral 
boards. Of most interest to this discussion are the processor 
boards which are based on the Intel 8080 or 8085 microprocessors 
and include varying amounts of on-board ROM and RAM mem- 
ory and I/O interfaces. In addition, the boards vary in the sophis- 
tication of their interrupt structures and timing facilities. In terms 
of abstract machines we might characterize these computers as 
essentially the same machine at the processor level but different 
machines at the computer system level. It was desired that the 
abstract machines defined by adding RMX to the underlying com- 
puters be as much the same as possible. 

During the design of RMX, we expected that its users would 
span the entire broad range of applications across which the SBC 
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hardware was being put to use. This implied that it might see uses 
ranging from minimal single board systems that functioned as 
single device controllers to complex multiboard applications im- 
plementing involved real-time process or industrial control func- 
tions. In particular we expected that many user-built I/O boards 
and peripherals would be used with the system. It was important 
for us to allow full use of these unknown devices with RMX while 
still providing as much assistance as possible in the building of the 
controlling software systems. 

As is the case with most processors, the concrete (i.e., physical) 
machines represented by the SBC family do not themselves in- 
clude any facilities to permit multiple asynchronous functions to 
be programmed, to provide for the coordination of such func- 
tions, or to provide time information needed for real-time ap- 
plications. Typically, users of these products have directly pro- 
grammed these functions in an ad hoc manner within their ap- 
plications. An examination of the sorts of functions necessary to 
such applications reveals that at the very least this reengineering is 
a waste of resources. Worse is the high probability of error in pro- 
gramming such critical functions. 

The SBC hardware products were designed to eliminate the 
complexities of board engineering, particularly for those users 
without the necessary expertise to handle the task, by functionally 
integrating individual components into complete boards. The 
programming of functions to coordinate parallel software activi- 
ties is, likewise, an area which should be carefully engineered in 
order to avoid subtle errors. The development of RMX was there- 
fore viewed as a process of functional integration analogous to 
the integration of LSI components into boards. That is, just as a 
well designed board relieves the user of component level hardware 
engineering, RMX relieves the users of low-level software engi- 
neering. 

B. System Requirements 

The hardware environments and anticipated uses of RMX de- 
fined a stringent set of requirements for it. Foremost among these 
were its memory constraints; indeed, for the anticipated uses, 
memory size considerations dominated execution speed ones over 
a considerable range. Since we expected applications that would 
reside entirely on a single board with 4K bytes of PROM, the 
maximum size of the RMX foundation code was set at half of this 
or 2K bytes. Further, unhke larger minicomputer systems, many, 
if not most, applications of the SBC boards would not have avail- 
able any mass storage or other program loading device. It was 
thus important that RMX be designed to be ROM (or PROM) 
resident and capable of automatically initializing the system when 
powered on. 

We also anticipated that the expertise of many RMX users 
would be in areas other than programming systems. We therefore 
felt that the RMX machine needed to provide a fairly simple set of 
concepts, avoiding where possible those constructs most likely to 
cause errors. For example, we felt that a very frequent source of 
programming difficulty lay in dealing with interrupts. Many 
latent errors in programming systems stem from the occurrence of 
an interrupt at an unexpected time. We therefore decided to at- 
tempt to minimize the need for users to deal with hardware inter- 
rupts or with the interrupt-like occurrences found in many mini- 
computer operating systems. At the same time we had to accom- 
modate the needs of the sophisticated user who still desired to 
take advantage of RMX but had a specific need to directly control 
the hardware via the interrupt facility. 

Finally, to define the general functionality of RMX we exam- 
ined its anticipated applications. Real-time applications com- 
monly need to perform a number of tasks of differing importance 



logically in parallel, with preference always being given to execut- 
ing the most critical ones first. While these tasks may be relatively 
independent, they may need to periodically synchronize them- 
selves with one or another distinct task or with the outside world. 
For the latter, interrupts are the usual hardware supplied mecha- 
nism. Some tasks may also need to communicate data with one 
another. For example, a task servicing a sensing device may take 
readings from the device which need to be communicated to two 
tasks: one task which reacts to the reading by controUing some 
other device, and another task which logs or tabulates the read- 
ings. Ranked in order of importance these might be control, sens- 
ing, and logging. Finally, the tasks must have the ability to con- 
trol themselves relative to real-time, either by delaying their exe- 
cution for certain periods or by guaranteeing that they are not in- 
definitely delayed by, for example, a fauhy device. 

Requirements on the system design were also generated by con- 
siderations internal to the design project. One of these was the 
need to provide a single RMX abstract machine on a variety of 
underlying SBC boards. While separate versions of RMX for each 
board could have been designed with the same external appear- 
ance, this approach would have led to an unnecessary amount of 
internal engineering. Additionally, without careful initial design, 
the differences in the base hardware would have had visible ef- 
fects on the RMX abstract machine for each of the boards. This 
requirement demanded that we partition the structure of RMX 
into two parts. One part would implement those aspects which 
were independent of the particular hardware. The second part 
would interface the first part to the underlying hardware of the 
specific boards [7]. 

We also wished to minimize the software development costs by 
applying the best available software engineering techniques. His- 
torically, tight space constraints have often led to a very ad hoc 
approach to software design in the belief that more generally 
designed external features or more modularly built internal 
designs would lead to inherently larger systems. As a result of this 
philosophy, each needed function is designed to be as small as 
possible. Unfortunately, while each function may be locally opti- 
mized, it is possible that the overall design suffers from duplica- 
tion or overlap between such individual elements. Current work 
in programming methodology stresses modularity, generality, and 
structure (most often for their side effects in producing more 
maintainable, less error prone systems). 

We felt that there was more to gain, both in development cost 
and space performance, by avoiding optimized specialization of 
function in favor of more general designs [17]. This reduced the 
number of separate functions that RMX had to supply. The re- 
suhing external design therefore has a single mechanism that pro- 
vides task communication, synchronization, time references, and 
standard interrupt-like control. To do so it incorporates the 
operating system design approaches favored in much of the mod- 
ern computing literature. Likewise, the internal structures are 
highly modular and designed to be as uniform as possible so as to 
avoid replicating similar, but nonidentical internal management 
routines. 



V. The RMX Machine 

B. General Concepts 

The abstract machine defined by RMX augments the base 
microprocessor by introducing some additional computational 
concepts. We define a task to be an independently executable pro- 
gram segment. That is, a task embodies the concept of a program 
in execution on the processor. RMX permits multiple tasks to be 
defined which can run in a parallel, or multiprpgrammed, 
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fashion. That is, RMX makes individual tasks running on one 
processor appear to be running on separate processors by manag- 
ing the dispatching of the processor to particular tasks. The reg- 
isters on the processor reflect the activity or state of the running 
task. Other tasks may be ready to execute but for some reason 
have not been selected to run yet and so have their processor 
states saved elsewhere in the system. From the point of view of the 
program that is a task, execution proceeds as though it were the 
only one being run by the processor. Only the apparent speed of 
execution is affected by the multiprogramming. From the point of 
view of the system, every task is always in one of three states: run- 
ning, ready, or waiting. The task actually in execution is running. 
Any other task which could be running but for the fact that the 
system has selected some other task to actually use the processor, 
is ready. Tasks which are delayed or stopped for some reason are 
waiting, as will be discussed below. 

Each task is assigned sl priority which determines its relative im- 
portance within the system. Whenever a decision must be made as 
to which task of those that are ready should be run next, the one 
with the highest priority is given preference. Furthermore, in the 
spirit of unifying mechanisms, the same priority scheme replaces a 
separate mechanism for disabling interrupts. Interrupts from ex- 
ternal devices are logically given software priorities. If the ap- 
plications system designer deems a particular task as of more im- 
portance than responding to certain interrupts, he can specify this 
by simply setting the RMX priority of that task to be higher than 
the RMX priority associated with those given hardware inter- 
rupts. It is thus possible to maintain a high degree of control over 
the responsiveness required for various functions. 

As mentioned above, tasks may desire to communicate infor- 
mation to one another. To this end the RMX machine defines a 
message to be some arbitrary data to be sent between tasks. To 
mediate the communication of messages it defines an exchange to 
be the conceptual link between tasks. An exchange functions 
somewhat like a mailbox in that messages are deposited there by 
one task and collected by another. Its function is complicated by 
the fact that a task may attempt to collect a message at an ex- 
change that is empty. In such a case the execution of that task 
must be delayed until a message arrives. Tasks that are so delayed 
are in the waiting state. We chose this indirect communication 
mechanism over one which directly addresses tasks because it per- 
mits greater flexibility in the arrangement of receiver and sender 
tasks. The anonymity of the receiving task impHes that the sender 
need know only the interface specification for a function to be 
performed via a message to a particular exchange. The task or 
tasks which implement that function need not be known and 
hence may be conviently changed if desired. 

The conventional mechanism used by programs to communi- 
cate with external devices is the interrupt. Unfortunately, inter- 
rupts are by nature unexpected events and programming with 
them tends to be error prone. The essential characteristic of an in- 
terrupt is that a parallel, asynchronous activity (the device) wishes 
to communicate with another activity (a program). Since this 
communication is essentially the same as that desired between 
separate software tasks it seems conceptually simpler to use the 
same message and exchange mechanism for it. The unification of 
all communications functions is analogous to the idea of stand- 
ardized I/O found in systems such as UNIX [17]. The RMX 
machine eliminates interrupts by translating them into messages 
which indicate that an interrupt has occurred. These messages are 
sent to specific exchanges associated with particular interrupts. 
Tasks which "service interrupts" do so in RMX by attempting to 
receive a message at the appropriate exchange. Thus, prioritized 
nested interrupts are easily handled. An advantage of this unfied 



treatment of internal and external communication is that hard- 
ware interrupts can be completely simulated via another software 
task. This facilitates debugging and permits easy modification of 
a system by allowing rather arbitrary insertion of tasks into a net- 
work of communicating tasks and devices. 

Note that with this scheme unexpected interrupts do not cause 
particular difficulty. For example, if the servicing task is still busy 
with some previous message, the interrupt message will be left at 
the exchange and will not affect the task until it is ready for an- 
other interrupt; i.e., until it waits at the exchange. In an apphca- 
tion designed to properly handle the actual interrupt rate, the task 
will service interrupts quickly enough to always be waiting when 
the next one occurs. In this case, response to an interrupt is im- 
mediate. Thus this mechanism provides no loss of facility relative 
to the usual interrupt scheme but it does make the proper con- 
trolling of such events simpler. Multiple occurrences of the same 
interrupt which indicate the processor has fallen behind in its ser- 
vicing are logged as such by a message which indicates that inter- 
rupts may have been lost. These interrupts do not, however, dis- 
rupt the running task or complicate programming. 

The last concept embodied in the RMX abstract machine is that 
of time. The RMX machine defines time in terms of system time 
units. It then permits tasks to delay themselves for given periods 
of time so that they can synchronize themselves with the outside 
world. It also permits tasks to guard against unduly long delays 
caused by attempting to collect a message at an empty exchange 
by limiting the length of time that they are willing to spend 
waiting for some message to arrive. 

B. Data Objects and Functions 

These concepts are reaUzed in RMX by introducing some new 
data objects and instructions. Just as the base processor can deal 
directly with such data objects as 8 bit bytes or unsigned integers, 
the RMX abstract machine can deal directly with the more com- 
plex data objects: task, message, and exchange. Each of these 
data objects consists of a series of bytes with a well defined struc- 
ture and may be operated upon only by certain instructions. This 
is completely analogous, for example, to a machine that permits 
direct operations on floating-point data objects which consist of 
four bytes with a particular internal structure to represent the 
fraction, exponent, and signs. In each case there are only certain 
instructions that can be used correctly with the object and the in- 
ternal structure of the object is not of particular interest to the 
programmer. 

The new instructions provided by RMX are: send, wait, ac- 
cept, CREATE TASK, DELETE TASK, CREATE EXCHANGE, and 

DELETE EXCHANGE. The Create instructions accept blocks of free 
memory and some creation information to format and initialize 
the blocks with the appropriate structure. Each corresponding 
delete instruction accepts one of the objects and logically removes 
it from the system. The remaining operations are of more direct 
interest to the operation of the RMX machine. 

The WAIT instruction has two operands: the address of an ex- 
change from which a message is to be collected and the maximum 
time (in system units) for which the task is to await the arrival of a 
message. The result of the operation is the address of the message 
which was received. A special message from the system indicates 
that the specified amount of time elapsed without the arrival of a 
normal message. From the programmer's point of view this in- 
struction simply executes and returns the specified result. Actual 
execution of the instruction will involve the delaying of task exe- 
cution if no message is available, by queueing it in a first-come- 
first-served manner at the exchange. Any such delay is not visible 
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to the programmer, however. This approach unifies the commun- 
ication and timing aspects of the design. It directly provides reli- 
ability in the face of lost events due to hardware or software fail- 
ure. Tasks can be guaranteed not to be indeterminately delayed 
due to such failures and can thus attempt recovery from them. It 
also permits tasks to use the same mechanism to delay themselves 
for given time intervals by waiting at an exchange at which no 
message will ever arrive. 

The ACCEPT instruction is an alternate way to receive a mes- 
sage. It has a single operand specifying the exchange from which 
the message is to be received and immediately returns either the 
next message at the exchange or a flag indicating that no message 
was available. The task is never delayed to await a message in the 
ACCEPT operation. 

SEND also has two operands: the address of a message and the 
address of an exchange to which the message is to be sent. The in- 
struction queues the message in a first-come-first-served manner 
at the exchange if there is no task already waiting there. If a task is 
waiting at the exchange then the instruction binds the message to 
the task and makes the task eligible to execute on the processor. 
When the receiving task resumes actual execution the address of 
the message will be returned to it as the result of its wait instruc- 
tion. 

VI. The RMX Implementation 
A. Methodology 

In this section and the next, we consider some (but certainly not 
all) details of the actual implementation of the system as illustra- 
tions of the design of such software products. We turn first to the 
methodology applied to the effort and then to some samples of 
the mechanisms. 

To provide the abstract machine just described and meet the 
other requirements for the system, RMX was implemented as a 
combination of ROM resident code and some RAM resident 
tables. Just as a hardware designer uses LSI devices in preference 
to more elementary TTL components, we chose to use the 
leverage of a high level programming language rather than 
elementary assembly code. The system was, therefore, designed 
using PLM 114], Intel's high-level implementation language. The 
operations described above appear as procedure calls using the 
standard PLM caUing sequence. The space constraints and a good 
level of internal maintainability were achieved by maximizing the 
modularity of the design. The broad independent functions of 
multiprogramming, communications and control were completely 
isolated from the board dependent timing and interrupt handling 
functions. As a result, movement of the system to a new member 
of the SBC family requires only the reimplementation of these 
board dependent functions. In addition, data structure of internal 
and user visible objects were generalized so that single ialgorithms 
could deal with any of them. Individual optimizations could have 
been made in the local design of many parts of the data structures 
to improve their space or time costs slightly. Such optimizations, 
however, would have cost considerably more in code space and 
code complexity [3]. 

The module feature of PLM was used to simulate the abstract 
data type concept 14], [13] and enforce information hiding [15], 
[16]. That is, every data structure used by RMX is under the ex- 
clusive control of a single module. The modules supply to each 
other restricted sets of public procedures and variables. It is only 
through these paths that agents outside a module may access the 
data structures maintained by the module. The only assumptions 
that such outside agents may make about a module and its data 
structures are those specified by the definition of the pubHc paths. 
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Fig. 2. Major modules (boxes) and data structures (circles) of RMX. 



As a result, so long as these interface specifications are main- 
tained, any given data structure may be reorganized by redesign- 
ing its controlling module without affecting other parts of the sys- 
tem. This approach improves the understandability of the imple- 
mentation and facilitates the debugging and maintenance of the 
system. Fig. 2 illustrates the general structure of the RMX imple- 
mentation. 

Finally, the original version of RMX was completely coded in 
PLM using the resident PLM compiler of the Intellec® Micro- 
computer Development System. This version was functionally 
complete but slightly exceeded the space constraints, occupying 
about 2.5K bytes of program space. There were a couple of cases 
where the language structure of PLM did not permit the direct ex- 
pression of the best way to compile the code. For these modules, 
it was sufficient to hand optimize the code output by the com- 
piler. The original structure of the PLM program was maintained 
and the majority of its generated code was used intact. The final 
RMX system occupies less than 2K bytes of program space. This 
high level language approach coupled with selective manual opti- 
mization permitted far quicker and more error free development 
than could have been achieved using assembly language. 

The approach to handling interrupts did introduce additional 
software overhead. For a typical configuration of the hardware, 
the realistic minimum interrupt latency would be about 200 /xs. 
Using the message mechanism it is about 800 fis. For the targetted 
process control applications, this is entirely acceptable. RMX 
does make provision, however, for direct handling of selective in- 
terrupts which require better response time without disturbing the 
use of the message mechanism for the others. For normal task 
communication, the performance is relatively better. For the typ- 
ical hardware configuration, the transmission of a message takes 
about 800 /IS, which is comparable to the time that would be re- 
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quired for any synchronization primitive (e.g., P and V or en- 
queue and dequeue) on such hardware. 



B. Engineering for Hardware Dependencies 

The two functions which vary most significantly across the SBC 
product line are the timing and interrupt facilities. To accom- 
modate these variations, the implementation separates the logical 
and physical parts of these functions. 

The interrupt facilities are split between the module which im- 
plements the communications operations and a hardware inter- 
rupt handler module. The communications module provides a 
special "interrupt send" operation which performs the logical 
translation of the interrupt event into a message. This facihty is 
independent of the interrupt structure of the processor board and 
remains the same in any version of RMX. The hardware depend- 
ent interrupt module deals directly with the hardware interrupt 
structure and invokes the serid operation at the logical level. Only 
this module need be redesigned when generating an RMX version 
for a different SBC board. With this approach we take full advan- 
tage of the hardware vectored priority interrupt structure on high 
performance products and can simulate this desirable structure at 
slightly higher software cost on low performance products. 

The same sorts of variations are faced in providing a source for 
the system time unit. Again, one module provides all of the 
logical time functions associated with providing time delays and 
time hmits to the user system. This module is independent of the 
type, frequency, or location of the physical time source. A sep- 
arate module is responsible for clocking the logical level by invok- 
ing it once every system time unit. Once again, this permits a con- 
sistent definition of time in RMX systems regardless of the sophis- 
tication of the available time source, and it limits the amount of 
reimplementation that is needed to support new SBC products. 

C. Example Data Objects 

As an example of the complex data objects defined in the sys- 
tem we will consider the task and exchange objects illustrated in 
Fig. 3. The task object is 20 bytes long and embodies the execu- 
tion state and status of a task. It consists of pointers used to link it 
onto various hsts of tasks in the system. These lists are used to 
queue a task at an exchange, link it to other ready tasks, or keep 
track of its maximum delay when waiting. It also contains the 
stack pointer of non-running tasks which is sufficient to supply 
the remaining task register values when the task next executes. 
Finally, the object contains the task priority, some status infor- 
mation describing the state of the task, and a pointer to auxiliary 
information about the task. 

The exchange object is 10 bytes long and implements the mail- 
box concept described earlier, primarily by serving as the source 
of header information for lists of messages and tasks. Each of 
these singly linked hsts is addressed with head and tail pointers 
located in the exchange object. All exchanges in the system are 
also linked together. 

The exchange objects are operated upon by the send, wait, 
and ACCEPT instructions of the RMX abstract machine. These in- 
structions generally alter the "value" or contents of these com- 
plex data objects. The task object is not the direct operand of any 
RMX instruction described above. Rather it is indirectly altered as 
a side effect of various instructions. Just as the user of floating- 
point objects on most machines needs to know the length and ex- 
istence of instances of the object, but not its internal structure, so 
the internal structure of these objects is generally unimportant to 
the users. 
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Fig. 3. Example data objects in RMX. 



D. Global Versus Local Optimizations 

We have already discussed some aspects of global versus local 
optimizations at the overall design level in terms of avoidance of 
redundant features. A good example of this tradeoff in the imple- 
mentation is provided by the linked Hst data structures within 
RMX. Like many such systems there are a number of singly 
linked hsts which must be maintained to reflect the status of the 
system. Local optimizations on the placement of hnks within data 
structures or in the form of the headers used for the lists would be 
guaranteed to save a few bytes of data space across the various 
hsts. Further, the hst insertion, scanning, and deletion algorithms 
could be specially tailored to the individual hst structures to save 
microseconds of execution time for some operations on some 
hsts. Indeed, any one such tailored algorithm might well use less 
code space than a single more general one. 

On the other hand, many of the hst operations are in no sense 
time critical. Generalizing all the list structures to use a single 
form replaces multiple algorithms with one, thus saving code 
space. The particular form can be chosen to favor those opera- 
tions that are frequent, thus limiting the impact of the generaliza- 
tion on the execution speed of the system. Perhaps most impor- 
tant, however, is that, by reducing the number of algorithms and 
structures used, we decrease the potential number of errors and 
improve the maintainability of the resuhant product. Since there 
are, for example, at least six distinct singly linked structures in the 
system, we reduce overall code size and engineering cost by sup- 
porting only a single mechanism. We improve product reliability 
at the price of a small increase in fixed data space and a small exe- 
cution speed penalty of infrequent and nontime-critical opera- 
tions. 

It is interesting to note as an aside that this is really an example 
of software engineering: that is, applying engineering discipline to 
software development. Such disciphne is highly valued and under- 
stood in other engineering fields. Standardized mechanical or 
electrical components are virtually always preferred to special 
designs; PLA's often replace random logic. Unfortunately, an ap- 
preciation of the overall benefits of such structure has been slow 
to develop in software engineering. Too often, we have seen 
special purpose designs and overly complex structure used in pro- 
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grams supposedly to save space or improve speed. The true costs 
in development time and reliability of such approaches have often 
been underestimated; the true time savings attributed to them 
often overestimated. The high percentage of end product cost due 
to software is finally forcing a general awareness of these issues. 

VII. LSI AND Abstract Machines 

It seems natural at this point to ask how the abstract machine 
view of systems in general and our experience with RMX might be 
affected by the continuing development of LSI technology. Once 
we view any complex software system as defining a collection of 
abstract machines, it becomes obvious that it is simply an engi- 
neering decision as to which machines should be committed to 
hardware. We are constrained in this choice by the densities of 
our solid-state technology, the performance we desire, the ap- 
plications that we are attacking, and perhaps most severely, by 
our understanding of software systems and of the machine struc- 
tures that they require. 

We might build an entire final application (e.g., a cash register) 
as a very-high-level single-chip machine. The specialization of 
such a design would, however, severely limit its application 
beyond the one for which it was specifically meant. On the other 
hand, we could build exclusively bit slice microprogrammable 
machines with utmost generality but which, due to their very low 
level of functional integration, would have no technological lever- 
age for attacking complex problems. Actually, both these ex- 
tremes have their well developed roles and will continue to be 
reasonable approaches for high-volume low-cost, and special- 
purpose tailored systems, respectively. It is in the middle ground 
—the area of the traditional computer— that directions are less 
clear. 

If the 8080 type processors are generally somewhat less power- 
ful than we actually need and as a result we always build operating 
systems of some level to support them, perhaps some of these 
functions can be integrated into the hardware. That is, if we can 
identify a broad range of systems which include essentially the 
same abstract machine implemented in software, then that 
abstract machine is a good candidate for hardware integration. 
The engineering difficulty is in understanding these software 
structures well enough to confidently and correctly commit them 
to hardware. 

Attempting to build all of some very large and complex operat- 
ing system onto one or two chips is, no doubt, out of the question 
with current technology. On the other hand, the final RMX sys- 
tem which we described resides in a small amount of ROM within 
the 65K address space of the 8080 processor. Once we view RMX 
as an abstract machine, the placement of the code which imple- 
ments its functionality becomes immaterial. In particular, we 
could build an augmented 8080 type processor directly by defining 
the additional instruction codes of RMX as hardware operations 
and moving the RMX implementation into microcode on the 
chip. The resultant component would indeed be an "RMX ma- 
chine" which dealt directly with the complex data objects and 
tables described above. It would have the advantage of not using 
any of the address space for operating system code. More impor- 
tantly, it would not waste bus cycles and memory access time 
fetching operating system instructions. Such a machine would 
have the same advantages over a conventional one that a machine 
with floating-point hardware has over one without it. 

Should we then try to build the RMX machine — ignoring for 
the moment whether our hardware technology is capable of it 
quite yet? Is the simple task model of RMX sufficiently general to 
be of use over a wide class of applications? Is the RMX machine 
the complete tool that we would like? Clearly, the answer is not a 



wholehearted yes. For one example, RMX provides no isolation 
or protection of one task from another. Indeed, no solely soft- 
ware system can provide such protection at any reasonable cost. 
Such isolation would be desirable at the least because it would 
limit the damage that one task could do to another due to errors. 
The conclusion to be drawn, therefore, is not that this particular 
abstract machine should be built in hardware, but rather that 
some such machine would provide more of the facilities needed 
for building microprocessor applications than do current proces- 
sors. Further, the design principles discussed above are the ones 
that appear most likely to be fruitful in creating such a machine. 

VIII. Conclusions 

In this paper, we have attempted to use a case study of a partic- 
ular small operating system to illustrate both a philosophical ap- 
proach to viewing computer systems and some important aspects 
of software development methodology. Many of the subtle as- 
pects of desiging software to control quasi-parallel activities have 
not been discussed in detail, nor have we fully described the im- 
plementation. Nevertheless, we hope that this description suggests 
the practicality and necessity of disciplined approaches to soft- 
ware system design. Until software implementation reaches a level 
of engineering commensurate with that applied to other aspects of 
computer system design, our products will be very much bound 
by software costs. Only discipline and structure within our soft- 
ware efforts will ultimately permit microprocessor applications to 
reach their full potential. 
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I. INTRODUCTION 

The introduction of the single board computer as a 
tool for the system designer has opened the way for 
many varied application areas to benefit from the 
advantages of computer utilization. A problem still 
exists, however, because the available I/O con- 
figurations have been largely incompatible with the 
wiring and packaging techniques required in indus- 
trial environments. This problem is overcome by 
the utilization of the Intel® iCS^'^ product family. 
The purpose of this application note is to provide a 
representative approach to the implementation of a 
computerized solution to an industrial control 
system. 

System Description 

This application note will deal with a control 
system which will regulate the temperature in each 
of four ovens. Each oven will be defined as utiliz- 
ing a light bulb for heating. Normal convection will 
be used to provide cooling. The internal tempera- 
ture will be measured by means of a thermistor in- 
stalled in each oven. We will assume that we will be 
required to implement some type of operator panel 
near the ovens which will allow the status of each 
oven to be monitored. This approach is similar to 
many common industrial applications which re- 
quire a supervisory control station in one area and 
a separate operator interaction panel near the 



equipment being controlled. The setpoint and tol- 
erances should be input from an external location. 

With these facts about our system defined, we can 
begin a step by step solution to providing a com- 
puterized control system to, operate the ovens. We 
will discuss the various equipment trade-offs and 
the decisions which will be used to define the hard- 
ware/software designs. 

Control Algorithm 

Before we can begin the design of our system, we 
must have a clear idea of the technique we will use 
to control the system. Our control system must 
maintain the oven temperature within a predefined 
and fairly narrow range of the setpoint. Let us 
make an assumption that the light bulb will be con- 
trolled digitally, meaning that the bulb must either 
be turned fully on or it must be turned fully off. 
The obvious control technique then becomes turn- 
ing the bulb on when the temperature of the oven is 
below our lower limit and turning the bulb off 
when the temperature is above the higher limit. It 
seems reasonable to assume that this technique will 
provide a temperature in the oven which varies 
sinusoidally with time. This is true because even 
though the lamp is turned off, it will continue to 
generate heat for a short period of time. Likewise, 
when the bulb is turned on, it will not instantly be 
able to provide heat to raise the temperature of the 
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chamber. We would expect to have a system re- 
sponse such as is shown in Figure 1. A better 
method of control can be devised if we provide 
some type of temperature prediction into our con- 
trol algorithm. Since this utilizes the rate of 
temperature increase or decrease, it will involve a 
type of derivative control system. This derivative 
control action will tend to dampen the temperature 
oscillations which might be encountered if only an 
instantaneous on-off control system were utilized. 
Figure 2 shows the response with time that we 
might expect with this type of control system. 
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Figure 1. Maximum Effort Current Temperature 
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The second approach is superior to the first 
because the control will provide a much smaller 
oscillation of the oven temperature. Other solu- 
tions are possible, such as providing a modulated 
output to the lamp. However, in an attempt to pro- 
vide a simple model upon which to expand our 
system solution, we will assume that the second ap- 
proach will provide us with an accurate enough 
control of the oven temperature. 

Having made the decision as to the control tech- 
nique, we can proceed with the task of determining 
the general system configuration. That is, we can 
define the physical system characteristics and the 
components to which we must interface the com- 
puter system. This approach is identical to that 
which would be used in a conventional control 
system design. 

Basic System Configuration 

Based upon the data which we have provided so 
far, it is possible to build a block diagram of the 
system's major components. The system consists 
of four ovens, an operator's panel, a data entry 
panel, and the actual control logic. A block dia- 
gram for the system is shown in Figure 3. We must 
now further define the elements which make up 
each of these blocks. 
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Figure 2. Maximum Effort Projected Temperature 



Figure 3. Application Block Diagram 

Each oven must consist of a heating element, which 
we have already defined as being a light bulb, and a 
temperature sensing element which we have said 
will be a thermistor. Each heating element will be 
switched on or off by applying or removing a 
source of 115 VAC. The thermistor temperature 
can be sensed by using the thermistor in a voltage 



3-6 



divider circuit. We can then measure the voltage 
across a fixed resistor to obtain an analog signal 
which is proportional to the oven temperature. We 
will determine the required value of the fixed 
resistor at a later time. 

The operator's panel should be designed to provide 
the workfloor operator with basic information as 
to the status of each oven. It should also allow 
some method by which he can inhibit the operation 
of any oven should it become necessary for charg- 
ing or servicing the oven. We can then define the 
basic elements which should make up the opera- 
tor's control panel. Each oven should have associ- 
ated with it the following controls and indicators: 

1 . Oven ON/OFF Switch — This switch will allow 
the operator to inhibit the oven operation by 
turning the appropriate oven switch to OFF. 

2. Oven RUNNING Indicator — This indicator 
will provide a visual indication that the oven is 
activated and that the temperature is being con- 
trolled. 

3. Oven IN TOLERANCE Indicator — This indi- 
cator will turn on when the oven temperature 
falls within the allowable bandwidth around the 
setpoint for that oven. 

4. Oven ALARM Indicator — This indicator is the 
complement of the in tolerance lamp. It will be 
turned on when the oven is activated and the 
temperature does not lie within the desired 
bandwidth. 

5. Oven CAUTION Indicator — It may be neces- 
sary to alert the operator to a potential oven 
temperature control problem before it actually 
occurs and sets off the alarm indicator. Since we 
have defined our control algorithm as utilizing a 
type of derivative control, we can project the 
oven temperature ahead in time. We will turn 
the oven caution indicator on when we predict 
that the oven temperature will lie outside of the 
desired bandwidth in a predetermined future 
time period. 

We have now defined the operator interface which 
we will utilize to control and monitor the oven 
processes. 

At this point, we will make a decision that the in- 
terface used to input the setpoints will utilize a 
CRT terminal. Though the decision may seem to be 
completely arbitrary, we will see later that CRT ter- 
minals provide an extremely useful device for 
allowing an operator to communicate with the sys- 
tem. Once the decision has been made, we have no 



further requirements to consider hardware design 
for this terminal, as the entire operation can be 
handled in the software development which will be 
considered later. 

A common technique for documenting a system is 
the ladder diagram. At this time, we can construct 
a ladder for our control system. Unlike conven- 
tional design techniques, our ladder diagram need 
only be concerned with the actual drive and sensing 
circuits since the logic required to drive the various 
outputs will be defined using software. This results 
in a considerable simpHfication of the design pro- 
cess. A ladder diagram for a typical oven is shown 
in Figure 4. We can defer the implementation of 
the control algorithm until we begin to develop the 
software portion of our control system. It is now 
possible to complete the external hardware design 
and to implement the system wiring package. 
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Figure 4. Ladder Diagram of One Oven 

II. WIRING INTERFACES 

A major pitfall in utiUzing a computer for control 
systems has traditionally been the requirement for 
the design engineer to expend a considerable 
amount of his time in designing interfaces to con- 
nect the physical wiring to the computer system. 
The introduction of Intel's product line of termina- 
tion panels has essentially eliminated the require- 
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ment of designing interfaces and allows more engi- 
neering time to be spent providing a solution to the 
application. Before we continue with the specific 
design, we should spend some time discussing the 
various types of termination panels available and 
the general characteristics of each panel. 

Analog Termination Panels 

The Intel® iCS 910™ Analog Termination Panel 
has been designed to provide a simple means of ter- 
minating the analog wiring and of providing an 
interface to the control system input/output. All 
wiring is terminated utilizing pressure type screw 
barrier blocks. Termination blocks have been pro- 
vided to allow the termination of up to 32 single- 
ended or 16 differential channels of analog input. 
For use in a differential input environment, such as 
we will be using, the terminator blocks provide wir- 
ing terminations compatible with shielded cable in- 
puts in that provision has been made to accept the 
shield of each input signal. The shield is then car- 
ried through the on-board circuits to the analog-to- 
digital converter. Provision has been made on the 
board for the mounting of commonly used circuits 
for signal conditioning. The available signal condi- 



tioning circuits provide for installation of current 
termination resistors and the installation of a single 
pole low pass filter network. The basic barrier 
assignments for the iCS 910 termination panel are 
shown in Figure 5. The possible circuit networks 
for this panel are illustrated in Figure 6. A com- 
plete description of the analog termination panel 
can be found in the iCS 910 Analog Signal Condi- 
tioning/Termination Panel Hardware Reference 
Manual (manual order number 9800800 A). 

The functions of the analog termination panel will 
become more clear as we develop the actual config- 
uration required to support our oven application. 
Referring to the ladder diagram (Figure 4) we see 
that a fixed resistor is necessary to provide the volt- 
age divider network to sense the oven temperature. 
The current termination resistor (Re) on the 
iCS 910 board can be used to provide a convenient 
mounting location for this component (refer to 
iCS 910 circuit schematic, Figure 6). At this point, 
we must make a design decision regarding the uti- 
lization of a low pass filter for our analog circuits. 
Since the oven temperatures are not expected to ex- 
hibit rapid fluctuations with time, the use of a low 
pass filter will not adversely effect the temperature 
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sensing. Indeed, the use of a low pass filter should 
contribute to spurious signal rejection should the 
analog cables pick up external noise signals. Calcu- 
lations will show that the use of a filter network 
consisting of UK ohm series resistors and a 2.2 /xF 
capacitor will provide the filter characteristics 
shown in Figure 7. 
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Figure 7. Single Pole Filter Characteristics 

Based upon our requirements and using the circuit 
schematic of Figure 6, we can provide the circuit 
interfaces required by our ladder diagram (Figure 
4) by configuring the channels of the iCS 910 ter- 
minator as shown in Figure 8. This results in a sim- 
ple two-wire per oven analog interface. The termi- 
nator board is designed to connect to the various 
analog I/O boards by means of a standard ribbon 



cable which is supplied with the terminator panel. 
The actual selection of the appropriate analog 
board will be deferred until later. We will define 
that oven number I will correspond to the differen- 
tial analog channel 0; oven 2 will correspond with 
channel 1; oven 3 will correspond with channel 2; 
and oven 4 will use channel 3. This leaves 12 analog 
differential channels available for future expan- 
sion. The channel selection just made was a purely 
arbitrary choice. 
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Figure 8. Analog Circuit for Oven Application 

The wiring to the iCS 910 terminator panel can 
then be made essentially as shown in Figure 9. 
Clearly, the use of the terminator panel greatly 
simplified the connection between the control sys- 
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Figure 9. Analog Terminator Wiring 
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tern and the physical devices which are to be moni- 
tored or controlled. Figure 10 shows the placement 
of the components onto the board. 
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Figure 10. Analog Terminator Component Locations 

Low Voltage Digital Termination Panels 

Looking again at our ladder diagram for an oven 
control system (Figure 4), we see the need to pro- 
vide a second type of interface signal. This is to 
provide the switching for the various indicator 
lamps used on the operator's control panel. Tradi- 
tionally, this interface has been handled by using 
electromechanical relays. The coils would be driven 
by the low voltage control system and the relay 
contacts were used to drive the external indicators. 
Modern technology provides us with a solid state 
device to perform the same function, the optical 
isolator. We can use these devices to provide a 
highly reliably and low cost alternative to the relay 
interface. The Intel® iCS 920™ Digital Signal Con- 
ditioning/Terminator Panel provides us with a 
convenient vehicle for mounting the optical 
isolator circuits and for terminating the wiring 
associated with the indicator devices. 

The iCS 920 panel is designed to be used by those 
interface circuits which incorporate operating volt- 
ages less than 50 volts and which generally use cur- 
rents which are smaller than 300 mA. These limits 
are given only for a general guideline since a wide 
variety of optical isolators and drivers are available 
for use on the board. Some of the devices are 
capable of handling greater voltages or currents. A 
representative Ust of available devices and com- 
plete details of the termination panel are available 
in the iCS 920 Digital Signal Conditioning/Termi- 
nation Panel Hardware Reference Manual (manual 
order number 9800801A). 



The digital panel provides terminations for up to 
24 digital channels, each of which can be con- 
figured as either an input or an output channel ac- 
cording to the specific application requirements. 
As with the analog termination panel, all wire ter- 
minations are made using pressure type barrier 
strips which will accept up to 16 gauge wire. The 24 
digital channels correspond with those input/out- 
put channels assigned to the standard Intel I/O 
configurations used on the single board computers 
and I/O expansion boards. We will dwell more on 
this subject later when we define the addresses 
associated with each circuit which we desire to in- 
corporate into the termination panel. 

Since the digital channels can be configured into 
either an input or an output mode, it is wise to dis- 
cuss each configuration so that a clear understand- 
ing of the board can be obtained, even though our 
application example will only use the output mode 
with this board. 

Figure 1 1 provides a schematic of the panel when it 
is configured for a digital input mode. To set up a 
channel to operate as an input, it is necessary to 
add at least two jumpers to the wire- wrap jumper 
posts. As can be seen, pins 6 and 4 must be con- 
nected together as well as pins 3 and 5. If the board 
is to provide a visual LED indication of the channel 
status, an additional jumper should be installed 
between pins 1 and 2 of the jumper posts. If this is 
done, be certain to take into account the additional 
current requirements when calculating the required 
input resistors. Two resistor mounting locations 
are provided to allow installation of selected com- 
ponents to handle the current Hmit through the 
optical isolator (Rx) and the threshold voltage for 
turn-on of the device (Ry). A complete and de- 
tailed procedure for selecting these resistors based 
upon the input voltages is provided in the iCS 920 
hardware reference manual mentioned earlier. Pro- 
vision has also been made on the termination panel 
for the installation of a diode (CR) to protect 
against reverse bias appUcation. 

The components have been placed on the board ar- 
ranged in groups of two channels. This eases the 
task of finding various components or of locating 
the holes for instaUing the required components. 
This layout is illustrated in Figure 12. It is impor- 
tant to take note of the physical placement of the 
optical isolator chips in the 20-pin socket. This in- 
stallation location must be followed rigorously 
when using a channel in an input mode. Also take 
note that provisions are provided for mounting two 
sizes of resistors in location (Rx). This will accom- 
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modate the power dissipation requirements which 
will be encountered in various application situa- 
tions. Referring again to Figure 12, note that the 
upper half of the layout represents odd channels 
and the lower portion of the layout is used for even 
channel component mounting. 




Figure 11. iCS 920^*^ Digital Terminator Input 
Configuration 

When the iCS 920 panel is used in this input mode, 
it corresponds to the utilization of a relay coil to 
sense some external contact closure. The resistors 
can be thought of as selecting the coil's operating 
voltage and the diode provides the same transient 



protection function as when installed on an electro- 
mechanical relay. Finally, the optical isolator out- 
put corresponds to the contacts associated with the 
relay coil. As we will see later, this approach pro- 
vides us with an unlimited number of contacts per 
relay coil. 

The oven application requires a contact for driving 
the indicator lamps associated with each oven. If 
we define the driving voltage to be 24 volts DC, we 
will find that the voltage and current requirements 
fall within the limits specified for using the iCS 920 
Digital Signal Conditioning/Termination Panel. 
Let us examine in more detail how this can be ac- 
complished. 

We will select an industrial indicator assembly 
which utilizes a full voltage 24-volt lamp. Typical 
lamps would be type 387. This will require a drive 
of 40 mA at 28 volts. Our switching device must be 
capable of driving this load. The analogy used 
earlier to compare the optical isolator with a relay 
in an input mode holds true when we utilize the 
devices in an output configuration. If we examine 
the data sheet for the current switching character- 
istics of a typical optical isolator, say the TIL 113 
(Appendix A), we can see that the current and volt- 
age requirements fall well within the allowable 
ratings of the device. We have selected the relay 
contact characteristics! We need not concern our- 
selves with the selection of current limitation 
resistors (coil voltage ratings) since this circuitry is 
provided on the terminator panel when a circuit is 




Figure 12. Digital Terminator Input Parts Layout 
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configured in an output mode. If we refer to Figure 
13, we can see the on-board schematic for the out- 
put drive mode of operation. Two jumpers must be 
installed for each output channel. The first, be- 
tween pins 1 and 2, is used to enable the LED chan- 
nel status indicator. The second, between pins 3 
and 4, actually connects the computer generated 
drive signal to the input of the optical isolator 
(analogous to connecting the relay coil to the driv- 
ing line). Provision has been made on the circuit 
board for only one optional component in the out- 
put mode; this is the resistor (Rz). This component 
has the effect of increasing the response time of the 
switching device. Because our indicator lamps are 
not time critical, we will choose to omit the instal- 
lation of this component. 
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Figure 13. iCS 920^*^ Digital Terminator Output Circuit 

Figure 14 provides a drawing showing the location 
of the components on the iCS 920 panel when it is 
utilized as an output switch. Again note the place- 



ment of the optical isolators in the 20-pin sockets. 
Also note the jumper arrangement used to provide 
the required output circuitry. 

Again referring to Figure 13, we see that an alter- 
native to using the optical isolator for a switch 
exists. Provision has been made on the panel for 
the installation of high power buffer/driver chips 
such as the TI 75462. This device provides the same 
coil/contact characteristics as our optical isolator; 
however, no isolation between the input and out- 
put is provided. In certain applications, this con- 
figuration may be desirable and can be imple- 
mented by connecting jumpers 1 and 3 together, 
then placing a jumper block in the isolator socket 
location. The oven application will not use this 
mode because of the many advantages which isola- 
tion can provide. 

Prior to actually installing the components onto 
the iCS 920 panel, it is necessary to assign the 
lamps to definite channel addresses. This involves 
making some additional assumptions and design 
configuration decisions. If we consider the total 
number of digital inputs and outputs which are re- 
quired to handle all four ovens (including the as yet 
unconsidered switch and heater signals), we see 
that a total of 24 channels will be required. These 
will be broken out as shown below: 
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Figure 14. Digital Terminator Output Configuration 
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We have indicated that the 16 indicator lamps can 
be handled using the iCS 920 panel. An examina- 
tion of the data sheets for the various Intel single 
board computers and expansion boards provides us 
with the fact that a common characteristic of most 
boards is the use of at least one Intel 8255 Pro- 
grammable Peripheral Interface. This provides us 
with at least 24 I/O lines with which to work on 
each single board computer. We can then assume 
that we will not require an I/O expansion board to 
implement our application. Ideally, we can handle 
our total requirements with one parallel interface. 

The various Intel parallel ports are brought off of 
the computer and expansion boards using edge 
connectors. These edge connectors are then con- 
nected to the termination panels using a standrd 
ribbon cable assembly, effectively providing an ex- 
tension of the I/O ports out to the termination 
panels. The 24 channels are grouped into three I/O 
ports (each consisting of 8 channels or bits) which 
are then called port A, port B, and port C. When 
connected to the iCS 920 panel, these ports and 
their bit assignments will be as shown in Figure 15. 

At this point, we seem to be in a dilemma since we 
would like to use all 24 channels and we have used 
only 16 of them on our panel while we have utilized 
the edge connector of the interface. It would be 
desirable to have some technique to extend the 
other 8 channels to a high voltage terminator 
panel. It might be well to interrupt our channel 
assignments at this time to jump ahead and con- 
sider the features of the iCS product line which will 
enable us to accomplish our interface desires. We 
will then consider the interface of the high voltage 
signals to our control system before returning to 
the problem of assigning port locations to our 
lines. 



High Voltage Digital Termination Panels 

The Intel® iCS 930™ AC Signal Conditioning/ 
Termination Panel is designed to interface up to 16 
AC signals (up to 280 volts at 3 amps) or high cur- 
rent DC signals (up to 50 volts at 3 amps) to the 
parallel ports of the Intel single board computers 
or I/O expansion modules. The barrier strip termi- 
nations on this panel are designed to easily handle 
the 14 gauge wire commonly found in applications 
requiring the use of the AC terminator. 

Solid state relays are used to provide the interface 
between the computer I/O ports and the physical 
plant devices. These devices make the utilization of 
the panel a simple task once a ladder diagram of 
the required circuits has been drawn. As we have 
previously mentioned and as is clear from looking 
at Figure 4, we shall need to utilize eight of the 
available circuits, four for input and four for out- 
put. The implementation of each signal type re- 
quires only that we insert the correct type of solid 
state relay into the appropriate socket. 

First,, consider the input configuration which is 
required to sense the position of the oven RUN 
switches. Figure 16 shows the circuit schematic 
when used in the input mode. We can see that the 
output signal will turn on when the input power is 
applied. Like the digital termination panel, each 
circuit's status is indicated by means of an LED in- 
dicator installed on the board. The input circuit is 
protected by a socketed 3-amp fuse which may be 
replaced without the need to solder any compo- 
nents. The solid state relay used for this configura- 
tion should be a type IAC5 which is available from 
either Opto-22 or Motorola. Complete details of 
available relays and their uses on the board are 
available in the iCS 930 AC Signal Conditioning/ 
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Figure 15. iCS 920^*^ Digital Terminator Port Assignment 
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Termination Panel Hardware Reference Manual 
(manual order number 98(X)802A). Keep in mind 
the fact that although this application note repre- 
sents the solid state relays as being actual relays and 
contacts, they in fact are solid state and contain no 
moving parts. 



allow the installation of the MOV and the snubber 
simultaneously. 
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Figure 16. iCS 930^" AC Terminator Input Circuit 

The output configuration is utilized to turn the 
heater elements (the light bulbs) on and off. Figure 
17 provides Us with a schematic of the output cir- 
cuitry. In this case, we will insert a soHd state relay 
of type OAC5 which will handle up to 140 volts 
RMS at 3 amps. In some cases, it might be desir- 
able to add certain components to the terminator 
panel when using it in the output mode. Two possi- 
ble circuit configurations are possible. The first 
and perhaps the most common will consist of in- 
stalling a MOV (metal oxide varistor) across the 
solid state relay contacts. This will be required 
when the load being driven is inductive in order to 
prevent the transients generated by the load from 
damaging the triac in the SSR (soHd state relay). 
Since the SSRs utilize zero voltage switching and 
the load in our ovens is resistive rather than induc- 
tive, our appHcation will not necessitate the instal- 
lation of this device. The second possibility for ad- 
ditional circuitry also involves driving inductive 
loads. When the load is highly inductive, a possi- 
bility exists that reliable operation of the SSR may 
not occur because of incorrect values for the dv/dt 
(a complete description of this phenomenon is 
available in various pubHcations available from the 
manufacturers of the soHd state relay devices). 
Provision has been made for installation of an ex- 
ternal snubber network should this be required. 
Again, our oven control system will not require this 
type of circuitry. Figure 18 is provided for refer- 
ence should the reader desire to see the location of 
the additional components on the panel. It should 
be noted that the component placement does not 
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Figure 17. iCS 930^'^ AC Terminator Output Circuit 




Figure 18. AC Terminator Component Locations 

We can now get back to the task of assigning ad- 
dresses to the various digital channels. The iCS 930 
panel has three connector options for connecting it 
to the computer's I/O ports. The standard con- 
figuration utilizes connector J2 to attach the rib- 
bon cable assembly. When this is done, the com- 
puter ports A and B will correspond to the 16 chan- 
nels on the terminator panel (Figure 19). If we look 
at the termination panel, we will see that there is a 
provision for the user installation of two additional 
ribbon connector sockets onto the board. These 
are used in order to utilize the computer port C. If 
connector J3 is installed and utilized instead of J2, 
the channel assignments will be as shown in Figure 
20. In a similar manner, connector Jl can be in- 
stalled and utilized to provide connections between 
the computer port C and the other eight SSR posi- 
tions. If we choose the 16 lines required for driving 
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the indicator lamps from the iCS 920 panel to be 
ports A and B, then it seems reasonable to assign 
the eight remaining lines required on the iCS 930 to 
port C. A feature of utilizing standard ribbon cable 
assembhes is the ability to easily add ribbon plug 
connectors to the cable. This will result in an 
assembly transferring ports A, B and C to the iCS 
920 panel (however, port C is not used) and which 
continues the port C signals to the iCS 930 panel. 



Individual channel assignments can now be made, 
grouping the inputs and outputs together in groups 
of four (this is done because of a requirement of 
the single board computers to share terminator and 
driver component packages in groups of four). Fig- 
ure 21 provides a drawing showing the channel 
assignments and the physical wiring locations 
which will be used to connect the oven heaters and 
switches. 
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Figure 19. iCS 930™ AC Terminator Port Assignments 
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Figure 20. iCS 930™ AC Terminator Port Assignments 




Figure 21. iCS 930™ AC Terminator Application Configuration 
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Final Channel Assignments 

The only task remaining before we have completed 
our task of assigning channel numbers and physical 
wire and component locations is to assign these 
channels on the iCS 920 digital termination panel. 
Since we have already determined that we will uti- 
lize ports A and B, this becomes a simple matter, 
requiring only an arbitrary assignment of lamp 
locations using these port bits. The assignments 
made for one oven can be seen in Figure 22. The 
entire ladder diagram of the system can now be 
completed along with port assignments for all sig- 
nals used. The completed diagram can be found in 
Appendix B. Note how the port assignments have 
been shown to the side of the ladder element repre- 
senting that interface device. 

The method used to define a port assignments 
needs to be clarified since it may not be apparent 
why a channel of port A was given the address of 
E80. To begin, we have already indicated that each 
port consisted of eight channels or bits. We will 
number these bits from to 7. Since it is possible to 
have many input/output devices connected to the 
computer, the possibility exists of having multiple 
devices which incorporate internally ports A, B, 
and C. The computer has been designed to support 
up to 256 of these ports so we have numbered them 
using the hexidecimal numbering system. The pos- 
sible port numbers can then range from 00 to FF. It 
will be found that a common characteristic of most 
single board computers is the use of assigning the 
port addresses of E8, E9, and EA to the on-board 
8255 parallel peripheral interface. Therefore, the 



first channel of port A would be defined as having 
an address of E80; the second channel of port B 
would be E91, and so forth. 



III. SELECTING THE COMPUTER BOARDS 

To this point we have delayed the selection of the 
boards which will be required to provide the com- 
puterized control system. The Intel OEM Micro- 
computer Systems Configuration Guide has been 
designed to simplify the task of selecting the re- 
quired system. Our first task is to enter all known 
information describing our desired system into the 
project configuration worksheets. These work- 
sheets can then be used to actually select a board 
configuration which meets our particular require- 
ments. The effort required to accompHsh the entry 
of data is reduced to a minimum through the use of 
predefined digital and analog configuration work- 
sheets. Our requirement of having a total of 24 
parallel data lines, consisting of a mix of high and 
low level interfaces, can be met by the 24-bit 
AC/DC combination. Our assignments of re- 
quirements for the terminator panels can be made 
and is shown in Figure 23. It can clearly be seen 
from the worksheets, that our required interface 
with the computer digital data will consist of one 
24-bit wide connector (had we not used port C 
assignments, the use of 16-bit wide connectors 
would have sufficed). This means that our selected 
single board computer or I/O expansion board 
must provide at least one edge connector having 24 
I/O bits on it. 




EXT5V 
POWER 



Figure 22. Digits! Panel Application Configuration 
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DIGITAL CONFIGURATION WORKSHEET 

PROJECT 

This worksheet will provide the required digital interface configuration 
data which is required to complete the Project Configuration Worksheet. 

Enter Number of Channels 

Enter # of Discrete AC Outputs (1 15-230 VAC) 4 (A) 

Enter # of Discrete AC Inputs (1 15-230 VAC) M (B) 

Enter # of Discrete DC Outputs (Current > 300 MA) Q (C) 

Enter # of Discrete DC Outputs (Current < 300 MA) \(d (D) 

Enter # of Discrete DC Inputs O (E) 



Compute the Number of iCS 920'" and iCS 930'** Termination Panels 

First compute the number of Parallel I/O ports (8-bits each port) required 
on your iSBC"* board. Round all computations up to the nearest whole 
integer unless instructed otherwise! 

Compute # of iCS 930 Interface Output Ports ((A + C)/8) L 

Compute # of iCS 930 Interface Input Ports (B/8) L_ 

Compute # of iCS 930 Termination Panels ((F + G)/2) L_ 

Compute # of iCS 920 Interface Output Ports (D/8) R 

Compute # of iCS 920 Interface Input Ports (E/8) O 

Compute # of iCS 920 Termination Panels ((J + K)/3) I 



(F) 
(G) 
(H) 
(J) 
(K) 
(L) 



Optimization of Digital I/O Port Usage for Minimum I/O Configuration 

Compute # of iCS 930 Output "Overflow Channels" DO NOT ROUND OFF) 

(A + C)/8 QUOTIENT O 

(Overflow Channels) REMAINDER M 

Compute # of ICS 930 Input Overflow Channels (DO NOT ROUND OFF) 

(B/8) . : QUOTIENT 

REMAINDER 4 

Compute # of iCS 920 Output Overflow Channels (DO NOT ROUND OFF) 

(D/8) QUOTIENT £ 

REMAINDER 

Compute # of iCS 920 Input Overflow Channels (DO NOT ROUND OFF) 

(E/8) QUOTIENT Q 

REMAINDER O 



Compute 8-Bit Input Ports Required (P + V) O 

Compute 8-Bit Output Ports Required (M+S) . ". 

Compute 4-Bit Output Ports Required ((N +T)/4) (ROUND UP) _J_ 



(M) 
.(N) 

. (P) 
(R) 

. (S) 
. (T) 

. (V) 
(W) 

(X) 

(Y) 

(Z) 
, (AA) 

(BB) 

(CC) 



Compute 4-Bit Input Ports Required ((R +W)/4) (ROUND UP) l_ 

Compute 8-Bit Port C Requirements ((Z + AA)/2) (ROUND UP) L 

Total I/O Parallel Ports Required (X + Y + BB). 5 

Total # of 24 Channel Parallel I/O iSBC Board Edge Connectors 

(CC/3) (ROUND UP TO INTEGER) 1 (DD) 

Compute Power Requirements for the Termination Boards 
(DO NOT ROUND OFF) 

Compute +5V for iCS 920 Board Outputs (.061 x D) AKp (EE) 

Compute +5V for iCS 920 Board Inputs (.023 x E) O- (FF) 

Compute +5V for iCS 930 Board Outputs ((.020^ (A + C)) J2fiQL(GG) 

Compute +5V for iCS 930 Board Inputs (.912xB) OHi (HH) 

Compute iCS 920 Power Requirements (EE + FF) -^(P ( JJ) 

Compute iCS 930 Power Requirements (GG + HH) A22l. (KK) 



Enter the appropriate data into the Project Configuration Worksheet as shown 
below: 



PROJECT CONFIGURATION WORKSHEET 



EQUIPMENT PARAfWIETERS: 




I "'""■ 


...tOCMUI.OU.f.. 








] 






ciSS., 




TiLL»LlJ 


„ 1 m 


•bV 1 -W 1 5» 1 I2» 


u., h h' 


«.,. 


:zT 


1 ' 

1 


r 


1 ■ 


















1 r —^ 


















^) : 




















1 1 
























1 ; 





















Figure 23. Digital Configuration Worltsheet 
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The required power requirements of the termina- 
tion panels can be calculated using the data pro- 
vided in the digital configuration worksheet. The 
information regarding the necessary connectors 
and the power requirements should then be 
transferred to the project configuration worksheet 
(Figure 24). 



EQUIPMENT PARAMETERS: 



PROJECT CONFIGURATION WORKSHEET 
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Figure 24. 



A similar technique is used to configure the analog 
signals using the standard analog configuration 
worksheet as shown in Figure 25. It can be seen 
that our appHcation will require a single cable con- 
nection to a differential input edge connector of an 
analog input board. The power requirements can 
be calculated from the current requirements to 
drive the thermistors and the sensing resistors. The 
data is entered into the appropriate columns of the 
configuration tables and then transferred to the 
project configuration worksheet. 



ANALOG CONFIGURATION WORKSHEET 

PROJECT OUEKJ OOV?mOLV.EPv 

This worksheet will provide the required analog interface configuration 
data which is required to complete the Project Configuration Worksheet. 

Enter Number ol Channels 

Enter » of Single Ended High Level Analog Channels O (A) 

Enter « ol Differential High Level Analog Channels H (B) 

Enter # of Differential Low Level Analog Channels O (C) 

Enter « of Analog Output Voltage Channels Q (D) 

Enter « ol Analog Oulput Current Channels O (E) 

Compute the Number ol iSBC" Board Edge Connectors 

Unless otherwise noted, round all computations to the next largest integer! 

Compute » of High Level Single Ended Analog Connectors (A/16)...,... _Q_ (F) 

Compute # ol High Level Differential Connectors (B/8) __L(G) 

Compute # ol Low Level Differential Connectors (C/8) O (H) 

Compute # of Analog Interface Input Connectors (F + G*H) I (J) 

Compute the Number ol ICS-910" Termination Panels 

Enter Analog Out Connectors (DM ♦ E/2) (K) 

Enter » ol Analog In Connectors (J/2) I (L) 

Enter Larger of (K) or (L) _J — (f^) 

Place the appropriate data Into the Project Conllguration Worksheet as shown 
below: 

PROJECT CONFIGURATION WORKSHEET 

EQUIPMENT PARAMETERS: 



--t-'i'-j 



i- 



Flgure 25. 



The only remaining physical element of our control 
system which we have not defined is the CRT ter- 
minal which will be used for setpoint entry and 
modification. Communications with a terminal re- 
quires that we provide a serial RS232C port in our 
control system. This port requirement is entered 



onto the worksheet and the system requirements 
are totaled as shown in Figure 26. 



EQUIPMENT PARAMETERS: 



PROJECT CONFIGURATION WORKSHEET 
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Figure 26. 



We must now choose the Intel iSBC boards which 
will provide a solution to our system requirements. 
This is done by referencing the summary of key 
iSBC configuration parameters to find boards 
which provide the necessary characteristics. Our 
first task is to choose a single board computer 
which meets as many of our needs as is practical, 
while providing performance characteristics ade- 
quate to our needs. 

Our first requirement for having support for a 
single RS232C serial communications channel can 
be seen to be met by a variety of possible boards. 
Among the possible boards meeting this require- 
ment are: 

iSBC 86/12™ iSBC 80/lOA™ 
iSBC 80/20™ iSBC 80/20-4™ 
iSBC 80/30™ 

We must look further before a final choice can be 
made. Again, it can be seen that all candidates also 
meet the requirement of providing a minimum of 
one 24-bit wide digital I/O connector. Our decision 
must be based upon parameters which are not 
necessarily related to the input or output capabili- 
ties. Even though we have not yet developed our 
software package for our control system, we can 
safely make some assumptions regarding the com- 
pleted software package and thus define additional 
requirements which will enable us to select our 
desired computer board. The softwaretask will be 
considerably simpHfied if we write our programs in 
a high level language and if we use available drivers 
for our input and output where they are available. 
As we will see, the utilization of JPL/M and 
RMX/80™ real-time executive and drivers will 
make this programming task much less demanding 
of our time. The trade-off is that these software 
tools take larger amounts of memory than if we 
were to write our entire appHcation program in 
assembly language. Let us make an initial estimate 
that our system will require about 8K of EPROM 
and in the neighborhood of 2K of RAM. 
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Entering this data on the configuration worksheet 
(Figure 27) enables us to narrow our choice by 
eliminating the iSBC 80/lOA since it does not have 
sufficient RAM on board. 



EQUIPMENT PARAMETERS: 






Figure 27. 



PROJECT CONFIGURATION WORKSHEET 
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Since our application is not likely to require exten- 
sive math handling capabilities or high speed capa- 
bilities, we probably do not need the power found 
in the iSBC 86/12; so we will remove this product 
from consideration. 

We are now faced with selecting either the iSBC 
80/20 board or the 80/30 board for our processor. 
Each has certain advantages and disadvantages for 
use in our application. Let's compare these two 
boards, considering first the iSBC 80/20, then the 
iSBC 80/30. 

iSBC 80/20 board advantages — Slightly lower 
cost, greater number of I/O Hues available. 

iSBC 80/30 board advantages — Faster proces- 
sor, dual ported memory, able to utilize UPI 
modules. 

If the system were to operate in a stand-alone en- 
vironment and we could be certain that significant 
expansion would not take place, we would prob- 
ably choose the iSBC 80/20 computer for our ap- 
plication. If we consider that the system might 
become a part of a much larger system by future 
expansions and additions, we should remember 
that the use of the UPI modules on the iSBC 80/30 
computer provides considerable power through 
multiprocessing capabilities. The dual ported 
memory can also provide us with the ability to use 
more sophisticated inter-board communication 
protocol should the need arise. For the purposes of 
this application note, we will assume the system is 
being designed for expansion and we will select the 
iSBC 80/30 computer. 

A good design practice is to provide an extra mar- 
gin of available memory in the hardware design. 
Our anticipated RAM memory will use about 2K 
bytes. The computer will provide us with 4K bytes 
so we have a considerable margin. This is not true 
when we look at the amount of EPROM available 
on the board. Our 8K requirement is identical to 



the amount of memory available to us on the 
board. We should consider the use of an expansion 
EPROM board or the prospect of having to spend 
a considerable amount of time reworking our pro- 
gram to get it to fit if we find that we have exceeded 
our estimates. We will select the option of adding a 
memory expansion board (it can be deleted if we 
find that our software requirements are less than 
estimated). 

The computer selection and the memory expansion 
board data can now be entered onto the configura- 
tion worksheet as shown in Figure 28. If needed, 
the addition of the memory expansion board will 
allow our EPROM requirements to grow up to 16K 
bytes. 



PROJECT CONFIGURATION WORKSHEET 

EQUIPMENT PARAMETERS- 
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The only requirement which we have not met is to 
assign a board to handle the analog input needs of 
our temperature sensing circuit. The analog voltage 
can be calculated and will be found to lie in the 
neighborhood of 4.6 volts at room temperature. 
This value will increase toward 5 volts as the 
temperature of the oven increases. Since we have 
no requirement for any analog output capabilities, 
we will choose the Intel® iSBC 711™ Analog Input 
Board to sense the voltage level. This board can be 
configured to handle a 5-volt full scale input and 
will provide a resolution of 12 bits. (If an oven re- 
quiring a wide range of temperatures and greater 
resolution were required, we would have to recon- 
figure our temperature sensor to provide a wider 
voltage spread over operating temperatures. For 
purposes of simplicity and clarity we will assume 
that our temperature resolution is adequate.) 

The configuration worksheet can be filled in to 
reflect the selection of the analog converter and the 
total power requirements for the system can be 
computed as has been done in Figure 29. We now 
need to select a chassis and power supply in order 
to complete the application hardware design phase. 

The Industrial Chassis 

Before the boards can be operated together to form 
a control system, a means of allowing communica- 
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SEE INSTIIUCTIOIf SHEET 

EQUrPMENT PARAMETERS: 



PROJECT CONFIGURATION WORKSHEET 
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Figure 29. 



tion between the boards and of distributing power 
among the boards must be found. This require- 
ment is met by specifying a chassis into which the 
boards will be mounted. The Intel® iCS 80™ In- 
dustrial Chassis provides an environment for oper- 
ating the boards which is specifically designed to 
operate in an industrial area. 

The chassis has been designed to facilitate mount- 
ing into either a standard 19-inch RETMA cabinet 
or it may be rear-panel mounted into an enclosure 
such as may be found in appHcations requiring the 
use of a NEMA electrical enclosure. The card chas- 
sis has been mounted in such a manner as to hold 
the single board computers and expansion modules 
vertically, facilitating maximum cooling of the 
boards. Fans are provided to aid the normal con- 
vection cooling process. Card racks may be in- 
stalled into the iCS 80 chassis to expand the card 
support capability to a maximum of 12 card slots in 
groups of four. Either an iSBC 635 or 640 power 
supply can be mounted into the industrial chassis 
to provide power up to 4 or 12 boards capability, 
respectively. 



Our application design requires the installation of a 
three board solution, so we will choose the iCS 80 
chassis with one iSBC 635™ power supply. We will 
choose to mount our control system in a standard 
NEMA 12 enclosure to protect the unit from the 
industrial environment. We should refer to the iCS 
80 Industrial System Site Planning and Installation 
Guide (manual order number 9800798) for com- 
plete details for selecting appropriate enclosures 
and installation instructions. 

The + 5 volt power needed to support the various 
termination panels and to supply a reference volt- 
age for the thermistors is available from a barrier 
strip located on the lower front of the iCS 80 
chassis (Figure 30). Our wiring can be routed to 
this barrier strip for those circuits requiring either 
5-volt DC or the system logic common. A fuse 
holder is provided and a fuse should be installed 
for system protection. We will install a 2-amp fuse 
into the holder (our maximum power requirement 
for external circuitry should be 1.22 amps accord- 
ing to Figure 26). 
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Figure 30. Industrial Chassis DC Power Strip 

The remaining terms required in our ladder dia- 
gram (Appendix B) consist of a high voltage 
neutral and a source of switched high voltage 
power for the heater lamps. Both of these terms are 
available from the iCS 80 industrial chassis. It is 
desirable to utilize the same switched power for 
both the computer system and our external signals, 
so that we can provide protection to operators 
when one portion of the system is shut down. A 
common source will insure that all portions of the 
system are inactivated if repair is being done. The 
iCS 80 chassis incorporates a heavy duty industrial 
key-lock switch for its power switching. The out- 
puts of this switch are available to the user at a ter- 
minal barrier strip located on a fold-out panel on 
the rear of the chassis assembly (refer to Figure 31). 
We can see that our neutral wire should be con- 
nected to terminal 5 (filtered AC low) and the wire 
for the AC high, wire #10 on the ladder diagram, 
should be connected to terminal 9. This will pro- 
vide us with a switched, fused, and filtered power 
source for our external wiring. 



As we will be installing the chassis into a NEMA 
enclosure, we will not want to use a standard power 
cord since this would involve the additional ex- 
pense of installing a duplex outlet in the cabinet. 
The power wiring can be installed directly onto the 
power barrier strip by placing the AC hot wire on 
barrier number 1, the neutral wire onto barrier 
number 4, and the ground onto barrier number 3. 

The hardware implementation of the system can 
now be considered to be complete. Before the sys- 
tem can function as a control for the oven temper- 
atures, we must define the relationships between 
the various pieces of the oven system and we must 
also define the operator interface with the CRT ter- 
minal. Thus, we begin the software phase of our 
design. 



IV. DETERMINATION OF SOFTWARE 
APPROACH 

The task of providing the relationships between the 
various system components falls into the category 
of writing the software. Before we actually begin to 
develop this software, we will define certain guide- 
lines which can be used to organize and simplify 
the task. 

Let us consider the general environment under 
which our programs will operate. We find that we 
have essentially two choices in this area. First, we 
can consider the entire process as a sequential set of 
predefined operations in which we must perform 
each operation before moving to the next until 
finally we complete the sequence and begin again. 
(This is analogous to using a single stepper switch 
to design our control system.) Since each oven is in- 
dependent of the others, we can not afford to use 
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this approach since we could get tied up-waiting for 
something to happen in a particular oven and 
would have to ignore the other ovens. The designer 
familiar with relay design will probably be think- 
ing, at this point, that we should use a separate 
sequential operation for each oven or device to be 
controlled. Indeed, this is exactly what we can do 
with our software by using what is known as a real- 
time executive. This tool will allocate the com- 
puter's resources in such a manner as to provide us 
with the capabihty of having independent software 
programs or tasks operating at what appears to be 
the same time. We will make our first assumption 
that our software will be written using such a tool 
and we will specify that we will operate under 
Intel's RMX/80 Real-Time Multi-Tasking Execu- 
tive. We will discuss more detail of this software 
tool as we develop our programs. 

Next, we must consider the language which we will 
use to actually define our required operation. We 
have many alternatives from which to choose. Let 
us look at several of the alternatives in some detail. 

Assembler 

Assembler language is probably the most basic tool 
with which we can program a computer. It is con- 
sidered to be the most efficient user of program 
memory and processor time. These features are 
made possible because each assembler instruction 
line is converted directly into a corresponding 
machine instruction. From a programming stand- 
point, assembler language is the most difficult to 
use since any task must be defined by subdividing 
that task into a multitude of smaller operations 
compatible with the available instructions of the 
computer. To use this language, we must be famil- 
iar with the architecture of each computer with 
which we desire to operate. The use of the language 
is somewhat simplified through the use of an Intel 
supplied assembler which converts the assembler 
code into machine instructions and provides hst- 
ings of the operations which have been entered. A 
complete description of the Intel 8080/8085 As- 
sembler Language is available in the 8080/8085 
Assembly Language Programming Manual (man- 
ual order number 9800301 B). 

The user should consider this programming tool 
when his appHcation requires the minimum 
amount of memory (such as might be required for 
very large volume designs where memory cost is a 
factor) or where a highly time dependent routine 



must be defined. Our oven application does not fall 
into either of these categories, so we will choose 
not to use this language in our instance. 



PL/M 

Intel's PL/M language offers an efficient, struc- 
tured, high level systems programming language. 
Before proceeding, let us be clear on the benefits of 
using a high level language. First, the use of high 
level languages results in reduced development time 
and cost. High level languages provide the ability 
to program in a natural algorithmic language. In 
addition, they eliminate the need to manage regis- 
ter usage or to allocate memory. Second, high level 
languages provide improved product reliability 
because programs tend to be written in structured 
formats and result in a minimum of extraneous 
branches which might cause testing problems. 
Finally, their use produces programs which are bet- 
ter documented and are easier to maintain. 
On the other hand, high level languages do not op- 
timize the code segments as well as can be done by 
an experienced assembly language programmer. As 
a result, most compilers (routines which convert 
the high level languages into machine executable 
code) use more program storage than those written 
by the assembly language programmer. Different 
languages and compilers require different amounts 
of memory for the same task. 

PL/M-80 is probably one of the most efficient high 
level languages for use on microcomputers. It has 
been determined that PL/M-80 users can expect to 
use between 1 . 1 to shghtly more than 2 times as 
much program memory as would be used for the 
same task written in assembly language. For this 
reason, we must place the use of this language high 
upon our list of possible languages in this appHca- 
tion. 

A glance at the PL/M-80 Programming Manual 
(manual order number 98-268B) indicates that the 
language is highly structured and seems to lend 
itself very well to handle logical type operations. It 
seems to have the greatest weakness in its math 
handling capabilities in that it does not support 
negative numbers or 4'ractions. It is reasonable to 
assume that the oven application can be handled 
entirely with positive integer numbers so this 
limitation will not unduly hamper our use of this 
language. We will keep these features in mind when 
making a final decision. 
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FORTRAN 

Intel's FORTRAN-80 provides the full subset of 
ANSI FORTRAN 77. In many cases FORTRAN- 
80 has features that exceed the specifications for 
both the subset and the full versions of FORTRAN 
77. Most of the power of this language lies in its 
ability to easily handle complex mathematical ex- 
pressions. Obviously, it does not have any limita- 
tions regarding fractions or sign of the numbers in- 
volved. It should be used when the appUcation re- 
quires the use of mathematical computations. The 
power of the language, however, means that the 
use of the language will take a heavy toll of mem- 
ory allocation. A complete description of the FOR- 
TRAN version supported by Intel and its use on the 
iSBC computers can be found in the FORTRAN- 
80 Programming Manual (order number 9800481 A) 
and in the ISIS-II FORTRAN-80 Compiler Opera- 
tor's Manual (order number 9800480). 

It is unlikely that the magnitude of mathematical 
routines required to control the temperature of our 
ovens will be complex enough to justify the use of 
FORTRAN. Keep in mind that, if such a situation 
were encountered, it is feasible to use a combina- 
tion of programming languages to create our final 
module. 

BASIC 

Certaintly the most well known high level program- 
ming language today is BASIC. It offers a quick 
way of applying the computational capabilities of 
the computer to a wide range of applications. The 
Intel RMX/80 BASIC-80 is an interpreter designed 
to operate with Intel's single board computers and 
contains extended disk handling capabilities. As an 
interpreter, it differs from other high level lan- 
guages in that it results in a relatively slower oper- 
ating solution to an application. It is also not possi- 
ble to use BASIC to generate multiple independent 
tasks which can compete for computer resources. 

For these reasons, we cannot consider the use of 
BASIC for a solution to our application. 

Final Selection of Language 

From the above discussion, it seems clear that our 
choice for the appHcation being demonstrated is to 
use PL/M-80 as our programming language. 

With this in mind, we can begin the task of actually 
generating the code which will complte our applica- 
tion and provide an operating control system. 



V. DEFINING SOFTWARE TASKS 

The software implementation can begin as soon as 
we have broken our control functions into inde- 
pendent "tasks". We can then handle each task 
separately as though it were the only thing which 
had to be done by the control system. In the event 
that we find that one of our tasks must communi- 
cate with or be interlocked with another, we will 
handle this need through the use of "exchanges". 
The "exchange" can be thought of as a mailbox in- 
to which messages are deposited and picked up by 
the various tasks. These messages convey the neces- 
sary information between the otherwise independ- 
ent programs. When all tasks have been coded, we 
will combine them using the facihties of RMX/80. 

Our oven application can be broken down into 
three functional areas or tasks. These are: 

1 . The Control Task which will be used to actually 
sense the oven temperature and to provide the 
required responses to the heaters and the indi- 
cator lamps. 

2. The CRT Update Task will be used to provide a 
"snapshot" of the system operations to a per- 
son viewing the CRT terminal. 

3. The Parameter Update Task will be used to ex- 
amine and update the oven setpoints and toler- 
ances. 

The choice of these three tasks has been essentially 
arbitrary in nature. Certainly, other choices and 
groupings of functions could easily have been 
made. We will use these choices for our example 
and will proceed with our development accord- 
ingly. 

We have two other supporting tasks which must be 
included in our system. Fortunately, these tasks are 
predefined and fully supported within RMX/80' s 
libraries; thus we need not write these functions. 
The two supporting tasks are: 

4. A Terminal Handler Task to support the actual 
interface to the CRT terminal. It provides echo 
of input characters and signals when data is 
ready to be read. It will output messages to the 
terminal and signal when all characters re- 
quested have been sent. 

5 . An Analog I/O Driver Task to request and han- 
dle the handshaking which is required to 
communicate with the analog input board. It 
will signal us when data has been input and is 
available for use by our user written tasks. 
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We can proceed with the implementation of each 
of our three tasks which we have defined. The first 
step with each will be to develop a flowchart which 
shows the required operations to implement that 
task. This flowchart will show any intertask com- 
munications or exchanges that may be required 
with other tasks. The flowchart can then be coded 
using the facilities provided by our programming 
language. 



those tasks to test for the presence of a message at 
the exchange before they get the temperature data. 
If no message is present, they must wait until one is 
placed into the exchange before proceeding. Just 
before we update the temperatures we will fetch the 
message from the exchange, leaving it empty while 
we work on the data, later we will again restore the 
message when the update is complete. 



Oven Control Task 

The sequence of operations required to perform 
the control task can be defined using the flowchart 
shown in Figure 32. Let us examine the required 
steps in more detail. 

An arbitrary decision has been made to only sam- 
ple and control the ovens once each second. This 
will allow some time for the system to respond once 
a heater output has been set. The first step in our 
control task is to wait for one second to elapse. 

Our next subtask should be to read the status of the 
various oven control switches pn the operator's 
control panel. This item could wait until a later 
time, but there is no harm in handling it at this 
time. 

Next, we see a block indicating the input of data 
regarding the current oven temperatures. This oven 
temperature data will certainly be used by the task 
handling the snapshot display on the CRT so we 
must give some consideration to the validity of the 
data. While we are in the process of getting the 
data and converting it to engineering units (next 
step), there will be periods during which the stored 
temperature data does not reflect the actual oven 
temperature. An example might be when we are ac- 
tually moving the 16 bits of the temperature since 
we can only move data 8 bits at a time. During this 
period, we would not want another task to use the 
data and since each task is going to operate inde- 
pendent of others, we must provide some type of 
lockout of the data while we are operating on the 
temperatures (an alternative would be to have each 
task get its own temperature from the A/D con- 
verter and convert it to engineering units, but this 
would seem to waste memory and computer time). 
We can provide this lockout by creating an ex- 
change to communicate with other tasks. If we 
make a message available in this exchange when the 
data is vaHd and cause no messages to be available 
when the data is nonvahd, we can effectively lock 
out tasks from using the data when it is in the pro- 
cess of being updated. This is done by requiring 
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The number obtained from the analog converter 
provides us with a value which is proportional to 
the temperature of the oven. Our next step is to 
convert this number into engineering units. Unfor- 
tunately, the voltage and temperature are not 
related in a linear fashion since the thermistor is a 
nonlinear device. We will have to develop a tech- 
nique to obtain a corrected value. For the purposes 
of this application note and in an attempt to keep 
the application as simple as possible, we have 
chosen to utilize a single table look-up to perform 
this conversion. Alternatives might have been to 
utilize FORTRAN routines to mathematically per- 
form the conversion or to have separate tables for 
each oven. Once the conversion has been made, we 
must return a message to the data lockout exchange 
to allow other tasks access to the data. 

Because we must deal with four ovens, the opera- 
tions related to each individual oven must be per- 
formed four times, once for each. This is easily 
handled as we will see, since PL/M is a block struc- 
tured language. Our flowchart rieed only remind us 
that the operations need be done four times. 

The next step has been defined as performing some 
digital filtering of the temperature by averaging the 
current temperature with the temperature of one 
second ago. This filtered value will be used to per- 
form subsequent computations and to make future 
decisions. 

We have defined earher in our definition of the 
control algorithm that we would use a derivative 
control. We have chosen to project the tempera- 
ture ahead for a period of 10 and 30 seconds. We 
must calculate the rate of change and the 
temperatures in 10 and 30 seconds so that this data 
will be available when needed. 

Now that the calculations have been made to deter- 
mine numeric values required for the decision mak- 
ing process, we must begin the process of determin- 
ing the status of each indicator and oven heater. A 
test will be made of the oven run switch and if it is 
found to be turned off, we will turn off all indi- 
cators and the oven heater associated with that 
oven. If the switch is found to be turned on, we will 
set the status of the "in tolerance*', "caution", 
and "alarm" indicators according to our oven con- 
trol algorithm. The oven heater will be turned on 
or off according to the projected temperature in 30 
seconds. 

Rather than output the individual oven indicator 
and heater data four times (once for each oven), we 



will perform the computations associated with 
making the decision four times (this saves code 
since we can use the same program steps with only 
pointers being exchanged). At the end of this time, 
a single operation will output the data to all ovens 
and indicators at the same time. Outputting to a 
computer port will actually cause the device to turn 
on or off according to whether the output bit is a 
one or zero. 

We will then return to the beginning of our task to 
wait until another second elapses before we again 
perform the indicated functions. 

Control Task Source Coding — The coding of our 
tasks is a straightforward procedure once we have 
prepared a flowchart. Since we are using PL/M-80 
and RMX/80, the coding sequence for a task will 
be as follows: 

1 . Define any variables or structures which will be 
used in the module. This involves providing in- 
formation defining variables as being either an 8 
or 16-bit variable and declaring if that variable 
is to be a part of the task being coded or is to be 
found in some other task. If any arrays or struc- 
tures are to be used, they must also be defined. 
Finally, if any program locations are to be used, 
they must be declared. 

2. The task must be initialized. That is to say that 
any assumptions which will be made as to initial 
data values in subsequent instructions must be 
initially forced to this initial value. 

3. The actual task must be coded to match the 
operations called out in the flowchart. 

We will look at some examples of this coding pro- 
cess using the control task flowchart. The complete 
listing of this module and all modules actually used 
to provide the oven control system can be found in 
Appendix C. 

At first glance, it would seem that the listing is ex- 
tremely complex, but as we will see it is made up of 
straightforward pieces. The listing is made up of 
three parts as we have mentioned above when de- 
fining the steps required to generate a program. 
The first part (line numbers 1 through 50) is used to 
define parameters, variables, and external ele- 
ments. The general types of elements making up 
this portion fall into typical categories. The first 
general category consists of DECLARE state- 
ments. Examples of typical lines will help explain 
their meanings (when actually developing the pro- 
gram, this first section was created piecemeal by 
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making an entry when it was found that a need for 
that term existed as the execution code in sections 
two and three were written). 

Examples of the '^declare'' statement are shown 
below. For example, on line 11 we find: 
11 1 Declare (n,k) byte; 

This means that the variables **n" and **k" are be- 
ing defined as terms which represent numbers or 
data which is one byte or 8 bits wide. The "11" is 
the program line number, and the *'!" indicates 
that we are in the first level of nesting. 

We can also see the use of the * literal" expressions 
such as used in Hne 4. The expression: 

4 1 DECLARE FALSE LITERALLY 'OOH'; 
means that we are creating a new instruction called 
'* false" and that its meaning is to be interpreted by 
the compiler as being equivalent to the value of 
zero. 

Rather than dwell on the declaration, let us move 
on to the coding process which was used to gener- 
ate the actual program. Keep in mind that the use 
of PL/M-80 requires that all terms used be de- 
clared in the program module. Refer to the PL/M- 
80 Programming Manual (order number 9800268B) 
for a full description of the PL/M language. 

Program Initialization — The initialization portion 
of the program can be found on lines 5 1 through 59 
of the control task program listing. This section is 
used to initialize data and to provide known entry 
conditions before we enter the repetitive program 
loop. This code is only executed when the system is 
reset or when the power is turned on. The control 
task requires two types of initializations; one to in- 
itialize the computer's output port and the other to 
set up the A/D converter. The requirements for 
each can be found in the RMX/80 User's Guide 
and the iSBC 80/30 Single Board Computer Hard- 
ware Reference Manual (order number 9800611 A). 
Actual instruction examples are given in these 
manuals for the initialization operations. 

Program Body — The program which actually pro- 
vides the control operations can be found on lines 
60 through 126 of the program listing for the con- 
trol task. It has been divided into sections which 
correspond directly to the flowchart that was 
prepared earUer. Most instructions in PL/M-80 
language follow closely the English structure which 
describes what is being done. The exceptions gener- 
ally follow definite predefined formats. The for- 



mat such as used on line 61 to wait for one second 
to elapse is an example of one such exception. Any 
time we desire to wait for a definite time period, we 
use an instruction of the form: 

MSG$PTR = RQWAIT (.DUMMY$EXCH, TIME DELAY); 

Whatever time delay we wish to use is expressed in 
increments of 50 msec time periods. Our example 
requires a time delay of one second so we will use 
the delay notation of 1 .0/0.050 = 20 time units (this 
command is actually caUing upon the RMX/80 ex- 
ecutive to handle the delay). 

The oven enable switch data has been defined by us 
to be routed by the hardware to the computer port 
*'EA" which converts to a decimal number, 234. If 
we define an internal memory location for this data 
and call it BLOCKO, then we can get the oven 
switch data by using an input statement. Since the 
data sense is inverted through the hardware, we can 
provide meaningful internal data if the signal is re- 
inverted as it is loaded into memory. The instruc- 
tion on line 62 of the control task listing performs 
this task. 

We are now ready to get the analog data from the 
A/D converter. Our flowchart shows that we must 
lock out the other tasks from access to the tempera- 
ture data during this time period, so we must first 
remove the enable message from the exchange in 
which it is stored. Messages are removed from an 
exchange by using an instruction of the form: 
STORAGE = RQ WAIT (EXCHANGE NAME,0) 

Line 63 of the program listing means that we will 
get a message from our storage exchange which is 
called 'Temp$lockout$exch" and store it in a 
memory storage area called "Lockout". Now, no 
other task can get a message from this exchange 
since it is empty, so it is permissible to operate on 
the temperature data. (Note how similar this com- 
mand is to the one used to wait for a delay. Indeed, 
this is the same request for RMX/80, but it re- 
quests a time delay of zero.) 

During the initialization, we built a message defin- 
ing the characteristics of the analog signals and of 
the analog conversion board which we are using. 
Remember that we have indicated that the task of 
getting this data from the board is provided to us by 
one of RMX/80' s predefined drivers. All that is 
necessary at this time is to inform that driver of our 
desire to get data, then wait until it has done its job 
and the data is available for us. The actual com- 
munication between our applications task and the 
analog driver is done using the idea of an exchange 
similar to that we have used to lockout the data. 
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We will send a message to the analog driver telling 
it what we want it to do, then we will wait until it 
sends a message back to one of our exchanges tell- 
ing us that it is done. The format for sending a 
message to an exchange always follows the form: 

CALL RQSEND (EXCHANGE NAME, MESSAGE NAME); 
Line 64 of the listing shows that we have requested 
the input of the analog data since we have sent our 
message, Convert, to the analog driver's exchange 
which is called RQAIEX. We will wait until the 
operation is complete by using the line of code 
shown on the hsting line 65. This is the same opera- 
tion type that we used to get our message back pro- 
viding a lockout earlier. The program will wait un- 
til a message is available before continuing. 

The data must now be converted into engineering 
units. We earlier indicated that we would use a 
table lookup to perform the linearization, so we 
have included this table as a part of our program at 
line 50. The offset into the table corresponding to 
our temperature must be determined so that the 
correct value can be stored. Because we have four 
ovens, we will perform the operation four times 
with the data each time corresponding to the ap- 
propriate oven. These operations can be followed 
on lines 77 through 81 of the listing. 

Lines 67 through 76 are used to establish an offset 
to be applied to the analog temperature data when 
the system is running. This program is only de- 
signed to be used during the start-up operations 
and is activated when a message containing a cali- 
bration request and current temperature is sent to 
its exchange. 

The temperature lockout must be renjNOved to 
enable other tasks to use this data. This is done on 
line 82 by sending the message back to the ex- 
change used for intertask lockout communications. 

The remainder of the program follows the flow- 
chart and the operations can be followed using a 
flowchart and the listing. Each element of the flow- 
chart corresponds to a block of code on the Hsting. 

CRT Update Task Development 

Earlier, we stated that the CRT update task would 
be used to allow the operator to view a ''snapshot" 
of the four ovens. Let us turn our attention to 
developing the software which is required to ac- 
complish this. We can begin by defining the ele- 
ments which we feel should be displayed, then 
defining the format to actually be used with the 
CRT terminal. 



Obviously, we need to provide the current tempera- 
ture of each oven on our display screen. If we dis- 
play the actual temperature, it seems reasonable to 
assume that we should also show the setpoint so 
that a determination can be made as to how well 
the system is performing. The control algorithm 
has been defined to use an allowable range to deter- 
mine system outputs, so it would seen wise to also 
show this parameter. Finally, we should inform the 
viewer of the status of the oven so that he will real- 
ize that the reason an oven temperature is low is 
because the oven is off rather than an oven mal- 
function. Other items could be added if desired by 
the system designer, depending upon the total sys- 
tem requirements or the characteristics of the 
users. 

We can now prepare a drawing of the CRT display 
to generate a layout of our desired characters and 
to generate an aesthetic display for viewing during 
operation. This drawing can be found in Figure 33. 

Several techniques are available to output the re- 
quired displays to the terminal. A decision must be 
made as to the frequency of screen updates; will we 
constantly refresh the data or do it only at certain 
intervals of time? If the terminal has the ability to 
disable the cursor, it makes sense to update data 
continuously. If the cursor cannot be disabled, its 
movement tends to be distracting, so the updates 
should be kept to a minimum. The terminal used 
for the application note did not have a disable 
feature, so we will make the decision to only up- 
date the screen once each second. 
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Figure 33. CRT Status Display Layout 

The decision to delay updates leads us to make 
another decision regarding the screen updates. If 
we only update a line which has data which has 
changed since the last update, the cursor move- 
ments will be kept at a minimum since it is unlikely 
that all parameters will ever change each second. 
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A flowchart can now be prepared showing the steps 
required to implement the CRT update task. This 
flowchart is shown in Figure 34. The coding of the 
program to support this task can be found in Ap- 
pendix C. The development is identical with that 
which we described in the sections regarding the 
control task. Again, the software is divided into 
three parts, the declaration statements from lines 1 
to 81, the initialization on Hnes 82 to 87, and the 
actual task code on lines 88 to 207. 
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Figure 34. CRT Status Flowchart 



A technique to exit from the CRT update mode 
and to get into a mode which will allow modifica- 
tion of the parameters has been introduced into the 
program and the display format. This is in the 
form of a message on the botton of the screen re- 
questing the entry of an escape character to adjust 
setpoints. The software has been written in such a 



manner as to test for a character inut from the key- 
board and if one is found corresponding to that 
character, the update task will allow the parameter 
update task to take control of the terminal (lines 
190 to 204 of the listing). 

Parameter Update Task 

The parameter update task is used to actually allow 
the modification of the setpoints and the tolerances 
associated with each oven. A second use of the task 
is to provide a tool for establishing the zero offset 
associated with each analog channel so that an off- 
set into the temperature linearization table can be 
computed by the control task. 

Figure 35 shows the flowchart which describes the 
steps required to perform these operations. When 
the task has been completed, we will return to the 
CRT update task. 
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Figure 35. Parameter Update Flowchart 
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The program code for this task can be found in Ap- 
pendix C and again follows the formats which we 
have discussed earlier. No attempt will be made in 
this document to provide a narrative of the listing 
since it follows the flowchart in development. 

Support Programs 

Three subprograms (procedures) have been written 
which provide functions which are common to the 
three tasks. This has been done to minimize repeat- 
ing code segments thus saving as much memory as 
possible. These three subprograms support: 

1. Conversion of a decimal string from the termi- 
nal into a binary number. This program is called 
ASC$2$BINARY and can be found in Appen- 
dix C. 

2. Storage for common variables used by more 
than one task. These variables could easily have 
been included in other tasks but a purely arbi- 
trary decision was made to include them in a 
separate module. 

3. Conversion of binary numbers into a decimal 
string suitable for output to the terminal. This 
program is called DECSREP and is found in 
Appendix C. 

We now have completed the coding of the software 
to support our oven application. We must finish by 
combining all the software together to form a 
single loadable module. 



VI. FINAL IMPLEMENTATION 

When all code was linked and loaded to form an 
executable program module, it was found that the 
system required 9,041 bytes of EPROM and 1,735 
bytes of RAM. These values fall within our hard- 
ware capabilities and will rquire that we program 
and insert nine EPROMs into the EPROM expan- 
sion card. 

The system can now be tested and installed to con- 
trol the ovens of our application. The actual system 
described in this application note has been con- 
structed and tested. It has been found to control 
the oven temperatures of four ovens and performs 
as we anticipated when we developed our control 
strategy earlier in this application note. 



VII. CONCLUSION 

We have shown how Intel's single board com- 
puters, industrial chassis, termination panels, and 
software can be configured to provide a solution to 
a typical control application. We have seen how the 
development of a solution to a control problem can 
proceed along a predetermined and logical path. 
Truly, the utilization of the microprocessors can 
lead to optimum and cost effective solutions to 
control applications. 
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APPENDIX A 
SELECTED DATA SHEETS 
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TYPES TIL113. TIL119 
OPTO-COUPLERS 

BULLETIN NO. DL-S 7312032, NOVEMBER 1973 



Gallium Arsenide Diode Infrared Source Optically Coupled 
to a Silicon N*P-N Darlington-Connected Phototransistor 

High Direct-Current Transfer Ratio . . . 300% Minimum at 10 mA 

Base Lead Provided for Conventional Transistor Biasing 

High-Voltage Electrical Isolation . . . 1500- Volt Rating 

Plastic Dual-ln-Line Package 

Typical Applications Include Remote Terminal Isolation, 
SCR and Triac Triggers, Mechanical Relays, and 
Pulse Transformers 



mechanical data 

The package consists of a gallium arsenide infrared-emitting diode and an n-p-n silicon darlington-connected 
phototransistor mounted on a 6-lead frame encapsulated within an electrically nonconductive plastic compound. The 
case will withstand soldering temperature with no deformation and device performance characteristics remain stable 
when operated in high humidity conditions. Unit weight is approximately 0.52 grams. 



fa 



Lr 




i.1 



tdS. 



■^I^^;;j~i, I 



NOTES: 

a. Leads are within 0.005 radius of true position 
(TP) at the gauge plane with maxlnnum material 
condition and unit installed. 

b. All dimensions are in inches unless otherwise 
noted. 

c. Pin 1 Identified by index dot. 

d. Terminal connections: 

1. Anode 

2. Cathode 

3. No internal connection 

4. Emitter 

5. Collector 

6. Base (For TIL119, make| 
no external connection) 



} 

)n 



Infrared -emitting 
diode 



Phototransistor 




absolute maximum ratings at 25° C free-air temperature (unless otherwise noted) 

Input-to-Output Voltage ±1.5 kV 

Collector-Base Voltage (TIL11 3) 30 V 

Collector-Emitter Voltage (See Note 1) 30 V 

Emitter-Collector Voltage 7 V 

Emitter-Base Voltage (Tl L1 13) 7V 

Input-Diode Reverse Voltage 3V 

Input-Diode Continuous Forward Current at (or below) 25°C Free-Air Temperature (See Note 2) .... 100 mA 
Continuous Power Dissipation at (or below) 25°C Free-Air Temperature: 

Infrared-Emitting Diode (See Note 3) 150 mW 

Phototransistor (See Note 4) 150 mW 

Total (Infrared-Emitting Diode plus Phototransistor, See Note 5) 250 mW 

Storage Temperature Range -55°Cto150°C 

Lead Temperature 1/16 Inch from Case for 10 Seconds 260°C 

NOTES: 1 . This value applies when the base-emitter diode is open-circuited. 

2. Derate linearly to 100°C free-air temperature at the rate of 1.33 mA/°C. 

3. Derate linearly to 100°C free-air temperature at the rate of 2 mW/°C. 

4. Derate linearly to 100°C free-air temperature at the rate of 2 mW/°C. 

5. Derate linearly to 100°C free-air temperature at the rate of 3.33 mW/°C. 



Texas Instruments 

INCORPORATED 

POST OFFICE BOX 5012 • DALLAS. TEXAS 75222 

Reprinted with permission from Texas Instruments, March, 1979. All rights reserved. 
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TYPES TIL113, TIL119 
OPTO-COUPLERS 



electrical characteristics at 25° C free-air temperature 



PARAMETER 


TESTCONDITIONSt 


TIL113 


TIL119 


UNIT 


MIN TYP MAX 


MIN TYP 


MAX 


V(BR)CBO 


Collector-Base 
Breakdown Voltage 


ic= IOmA, 


Ie = 0, 


Ip =0 


30 




V 


V(BR)CEO 


Collector-Emitter 
Breakdown Voltage 


IC "^ 1 mA, 


Ib = o, 


lF=0 


30 


30 


V 


V(BR)EBO 


Emitter-Base 
Breakdown Voltage 


iE= IOmA, 


ic = o. 


lF = 


7 




V 


V(BR)ECO 


Emitter-Collector 
Breakdown Voltage 


Ie = lO^A, 


If = 






7 


V 


'C{on) 


On-State 
Collector Current 


VcE = 1 V. 


Ib = o, 


Ip = 10mA 


30 100 




mA 


VCE-2V, 


If = lOmA 






30 160 


'C(off) 


Off-State 
Collector Current 


VcE = 10 V, 


Ib = o, 


lF = 


100 


100 


nA 


hpE 


Transistor Static 
Forward Current 
Transfer Ratio 


VcE = 1 V, 


IC = 10 mA, 


lF = 


15,000 






Vf 


Input Diode Static 
Forward Voltage 


If = 10 mA 


1.5 


1.5 


V 


VCE(sat) 


Collector-Emitter 
Saturation Voltage 


IC = 125 mA, 


Ib = o, 


Ip = 50 mA 


1 




V 


IC= 10 mA, 


If = 10 mA 






1 


no 


Input-to-Output 
Internal Resistance 


Vin-out=±1.5kV, 


See Note 6 




lOll 


1011 


n 


Cjo 


Input-to-Output 
Capacitance 


Vin-out = 0, 


f= 1 MHz. 


See Note 6 


1 1.3 


1 1.3 


PF 



NOTE 6: These parameters are measured between both input-diode leads shorted together and ail the phototransistor leads shorted together. 
^ References to the base are not applicable to the Tl L1 19. 

switching characteristics at 25° C free-air temperature 



PARAMETER 


TEST CONDITIONS 


TIL113 


TIL119 


UNIT 


MIN TYP MAX 


MIN TYP MAX 


tp Rise Time 


VcC=15V, lc(on) = 125 mA, 
R|_= 100 il. See Figure 1 


50 




MS 


tf Fall Time 


50 




tr Rise Time 


Vcc=10V, lc(on) = 2.5 mA, 
R|_= 100 n. See Figure 1 




50 


MS 


tf Fall Time 




50 



r" 



PARAMETER MEASUREMENT INFORMATION 



JTl 



^ j-^VW O INPUT 



vcc^ 




Adjust amplitude of input pulse for: 
IC(on) = 125mA (TIL113) 
IC(on) = 2.5mA (TIL119). 



%_r 



O OUTPUT 
R L = 1 00 n 



90% 





TEST CIRCUIT 



•10% 10%- 

VOLTAGE WAVEFORMS 



NOTES: a. The input waveform is supplied by a generator with the following characteristics: Zq^^ = 50 fi, t^ < 15 ns, duty cycle « 1 %, 
tyv = 100 ms. 
b. The output waveform is monitored on an oscilloscope with the following characteristics: t^ < 1 2 ns, Rjp > 1 Mfi, Cjn < 20 pF. 

FIGURE 1-SWITCHING TIMES 
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TYPES TIL113, TIL119 
OPTO-COUPLERS 



TYPICAL CHARACTERISTICS 



TIL113 

COLLECTOR CURRENT 

vs 

COLLECTOR-EMITTER VOLTAGE 



120 




0.4 0.8 1.2 1.6 2.0 

VcE-Collector-Emitter Voltage-V 

FIGURE 2 

TIL113 

COLLECTOR CURRENT 

vs 

INPUT-DIODE FORWARD CURRENT 
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TIL119 

COLLECTOR CURRENT 

vs 

COLLECTOR-EMITTER VOLTAGE 
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p^T^ 




f- 




/ \f = 30 mkj^^ 


<:^ 




\ lF'=40mA 
1 II 
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lF = 


50 mA 
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'Ib = o 

Ta = 25°C 
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See Note 7 
1 1 



0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2 
VcE~Collector-Emitter Voltage-V 

FIGURES 

OFF-STATE COLLECTOR CURRENT 

vs 

FREE-AIR TEMPERATURE 
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1^ 



100 - 
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VCE = 
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lF = 






/ 
















/ 










/ 








/ 











2 4 7 10 20 40 

I p— Forward Current— mA 



70 100 



25 50 75 100 

Ta— Free-Air Temperature— °C 



125 



FIGURE 4 

NOTE 7: Pulse operation of input diode is required for operation beyond limits shown by dotted line. 



FIGURE 5 
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TYPES TIL113, TIL119 
OPTO-COUPLERS 



TYPICAL CHARACTERISTICS 



cn 

O 
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CO h- 
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TIL113 

RELATIVE COLLECTOR-EMITTER 

SATURATION VOLTAGE 

vs 
FREE-AIR TEMPERATURE 
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T/\— Free-Air Temperature— °C 



TIL113 

TRANSISTOR STATIC FORWARD 

CURRENT TRANSFER RATIO 

vs 

COLLECTOR CURRENT 
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Ic-Collector Current— m A 
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FIGURE 6 



FIGURE? 
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INPUT DIODE FORWARD 
CONDUCTION CHARACTERISTICS 



See 


Not 


e8 
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rA = 


70°( 


Jj 
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Va 


'/ 


Ta = -SB^C 

1 1 



0.2 0.4 0.6 0.8 1.0 1.2 1.4 1.6 1.8 2.0 

Vp— Forward Voltage-V 

FIGURES 

NOTE 8: This parameter was measured using pulse techniques, t^^ = 1 ms, duty cycle < 2%. 
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OPTO 22 



I/O Module Detail 
Electrical Specifications 



AC INPUT 
MODULES 


MODEL MODEL MODEL 
IAC5 IAC15 IAC24 


MODEL 
IAC5-A 


MODEL 
IAC15-A 


MODEL 
IAC24-A 




AC INPUT LINE 


95 to 


180 to 
280 VAC 








VOLTAGE 


130 VAC * 






* 


INPUT CURRENT 












AT RATED LINE 










* 


ISOLATION 


'^'inn Vnit RMR 










INPUT TO OUTPUT 










* 


INPUT ALLOWED 


.5 ma 










FOR NO OUTPUT 










' 


TURN ON TIMF 










' 














TURN OFF TIME 






















: 


OUTPUT TRANST 


30 Volt'^ DP 










BREAKDOWN 










* 


OUTPUT CURRENT oc rr,^ . 












. 


OUTPUT LEAKAGE 












30VDC, NO. INPUT 












OUTPUT VOLTAGE 


A Voltt nt S^i mn Lox^d 










DROP 










' 


LOGIC SUPPLY 
VOLTAGE DC 


4.5 to 12 to 20 to 
6V 18 V 30 V 


4.5 to 
6V 


12 to 
18V 


20 to 
30 V 




LOGIC SUPPLY 
CURRENT 


12 ma 15 ma 18 ma 


12 ma 


15 ma 


18 ma 






AC OUTPUT 
MODULES 


MODEL MODEL MODEL 
0AC5 0AC15 OAC24 


MODEL 
0AC5-A 


MODEL 
0AC15-A 


MODEL 
OAC24-A 


LINE VOLTAGE 


12 to 


24 to 
280 VAC" 








140 VAC 






^ 


CURRENT RATING 


3 Amps® 


















* 


1-CYCLE SURGE 




















* 


SIGNAL INPUT 
RESISTANCE 


220 1K 2.2K 
Ohm Ohm Ohm 


220 
Ohm 


IK 
Ohm 


2.2K 
Ohm 




SIGNAL PICKUP 
VOLTS DC 


3V 9V 18V 
8VAId.* 16V Aid.* 32V Aid.* 


3V 
8V Aid.* 


9V 
16V Aid.* 


18V 
32V Ale 


1.* 


SIGNAL DROPOUT 


1 Volt 










VOLTS DC 










* 


PEAK REPETITIVE 


400 V ■ *- 


500 Volts 








VOLTAGE 






* 


MAXIMUM 


1 6V 










CONTACT DROP 










' 


OFF STATE 


t; mn RM*i 










LEAKAGE 












MINIMUM 


on 










LOAD CURRENT 










* 


ISOLATION 


'"inn ynW" rm9 








* 


INPUT TO OUTPUT 












CAPACITANCE 


8 Pf 










INPUT TO OUTPUT 










' 


STATIC 


Onn V/nlt'^/Mirrn'^nrnnH Min 










DV/DT 










* 


COMMUTATING 


Built in snubber (will commutal 
.5 power factor loads) 


:e 








DV/DT 








* 



DC INPUT 
MODULES 


MODEL MODEL 
IDC5 IDC15 


MODEL 
IDC24 




INPUT LINE 


in qo vnr 




' 


VOLTAGE 








INPUT CURRENT 


32 ma at 32V 










* 


ISOLATION INPUT 


'?'^nr\ \/oit RMc? 






TO OUTPUT 






. ' 


CAPACITANCE 


8 Pf 






INPUT TO OUTPUT 






* 


INPUT ALLOWED 








FOR NO OUTPUT 






* 


TURN ON TIME 


5 Millisecond Max - 








' 


TURN OFF TIME 


5 Millisecond Max - 










' 


OUTPUT TRANST 


30 Vnitt DC 






BREAKDOWN 






* 


OUTPUT CURRENT 25 ma 




— 


OUTPUT LEAKAGE 


lOOMicroampsMax 






30 VDC NO INPUT 






OUTPUT VOLTAGE 


A VnIt nt P'i mn 






DROP 






* 


LOGIC SUPPLY 
VOLTAGE 


4.5 to 12 to 
6V 18V 


20 to 
30V 




LOGIC SUPPLY 
CURRENT 


12 ma 15 ma 


18 ma 






DC OUTPUT 
MODULES 


MODEL MODEL 
0DC5 0DC15 


MODEL 
ODC24 




LOAD VOLTAGE 


60V 






RATING 


DC 






OUTPUT CURRENT 
RATING 


3 Amps® 




— 


OFF STATE 
LEAKAGE 


1 ma Max 




— 


ISOLATION 








INPUT TO OUTPUT 








SIGNAL PICK UP 
VOLTAGE 


3V 9V 
8VAId.* 18V Aid.* 


18V 
28V Aid.* 




SIGNAL DROP 


IVolt 






PUT VOLTAGE 








SIGNAL INPUT 
RESISTANCE 


220 IK 
Ohm Ohm 


2.2K 
Ohm 




1 SECOND SURGE 








5 Amp^ 




* 


TURN ON TIME 






* 








TURN OFF TIME 


"^ <^ K/lilli<*nmnH 










* 



* Allowed 
©Derate .033 Amps per degree C from 20° C 



*Allowed 



_SJ # I i « W-^-^^ 
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Reprinted with permission from OPTO 22, March, 1979. All rights reserved. 



3-36 



High Voltage DC Output Modules 



*AI lowed 



DC OUTPUT 
MODULES 


MODEL 
0DC5-A 


MODEL 
0DC15-A 


MODEL 
ODC24-A 




LOAD VOLTAGE 
RATING 


200V 
DC 






— 


OUTPUT CURRENT 


A 






' 


RATING 


Amp„ 








OFF STATE 










LEAKAGE 










ISOLATION 


2500 V RMS 








INPUT TO OUTPUT 








SIGNAL PICK UP 
VOLTAGE 


3V 
8V Aid.* 


9V 

18V Aid.* 


18V 
28V Aid.* 




SIGNAL DROP 










OUT VOLTAGE 










SIGNAL INPUT 
RESISTANCE 


220 
Ohm 


1K 
Ohm 


2.2K 
Ohm 




1 SECOND SURGE 










5 Ampv, 








TURN ON TIME 


500 Microse 






' 








TURN OFF TIME 


2.5 Milliseco 















Fast Switching DC Input Modules 




DC INPUT 
MODULES 


MODEL MODEL 
IDC5-B IDC15-B 


MODEL 
IDC24-B 




INPUT LINE 


4 16 VDC 






VOLTAGE 








INPUT CURRENT 














ISOLATION INPUT 








TO OUTPUT 


<io(JU voii HMo 






CAPACITANCE 


8 Pf 






INPUT TO OUTPUT 








INPUT ALLOWED 








FOR NO OUTPUT 








TURN ON TIME 














TURN OFF TIME 


1 00 Microsecond Max — 










OUT TRANSISTOR 


qrj Vnlt" nP 






BREAKDOWN 








OUTPUT CURRENT 


05 PP3 










* 


OUTPUT LEAKAGE 






' 


30 VDC NO INPUT 








OUTPUT VOLTAGE 








DROP 








LOGIC SUPPLY 
VOLTAGE 


4.5 to 12 to 
6V 18V 


20 to 
30V 




LOGIC SUPPLY 








CURRENT 
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OF INTEL CORPORATION. 
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APPENDIX C 
PROGRAM SOURCE LISTINGS 



USING INTEL'S INDUSTRIAL CONTROL SERIES IN CONTROL APPLICATIONS 



$TITLE ('CONTROL TASK') 

/*•********************* **:/k******** ******************* 

* This task handles the control and monitoring of * 

* four oven chambers. *. 
*****************************************************/ 

1 CONTROL$TASK$MODULE : 

Do; 

2 1 DECLARE EXCHANGE$DESCRIPTOR LITERALLY 'STRUCTURE ( 

MESSAGE$HEAD ADDRESS, 
MESSAGE$TAIL ADDRESS, 
TASK$HEAD ADDRESS, 
TASK$TAIL ADDRESS, 
EXCHANGE$LINK ADDRESS)'; 

3 1 DECLARE TRUE LITERALLY '0FFH'; 

4 1 DECLARE FALSE LITERALLY '00H'; 

5 J DECLARE BOOLEAN LITERALLY 'BYTE'; 

6 1 DECLARE FOREVER LITERALLY 'WHILE 1'; 

7 1 DECLARE MSG$HDR LITERALLY ' 

LINK ADDRESS, 
LENGTH ADDRESS, 
TYPE BYTE, 
HOME$EX ADDRESS, 
RESP$EX ADDRESS'; 

8 1 DECLARE MSG$DESCRIPTOR LITERALLY ' STRUCTURE ( 

lv)SG$HDR, 

REMAINDER(l) BYTE) ' ; 
/* AIMSG.ELT - ANALOG INPUT REQUEST MESSAGE FORMAT */ 

9 1 DECLARE ATMSG LITERALLY 'STRUCTURE( 

MSG$FIDR, 
STATUS ADDRESS, 
BASE$PTR ADDRESS, 
CHANNEL$GAIN ADDRESS, 
ARRAY$PTR ADDRESS, 
COUNT ADDRESS, 
ACTUAL$COUNT ADDRESS)'; 
/* AITYP.ELT ~ ANALOG INPUT MESSAGE TYPES */ 
10 1 DECLARE AIREP LITERALLY '30', 

AISQS LITERALLY '31 ' , 
AISQV LITERALLY '32' , 
AJRAN LITERALLY '33'; 
Declare (n,k) byte; 
Di Clare (MSG$PTR, LOCKOUT) address; 

Declare (BLOCK0 ,BL0CK1 ,BLOCK2,BLOCK3) byte external; 
Declare TOLERANCE (4) address external; 
Declare TEMP (4) address external; 
Declare SETP0INT(4) address external; 
Declare T$AVERAGE(4) address; 
Declare T$LAST(4) address; 
Declare T$LAST$AVERAGE (4 ) address; 
Declare T$t5(4) cddress; 
Declare T$tl0(^) address; 
Declare STATUS (4) byte external; 

Declare CRT$DISPLAY$LOCK (5) address external; 
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11 




12 




13 




14 




15 




16 




17 




18 




19 




20 




21 




22 




23 





2A 




25 




26 




27 




28 




29 




30 




31 




32 





Declare TEMP$CALIBRATE (5) address external; 
Declare DUMMY$EXCH (5) address externals- 
Declare TEMP$LCCK0UT$EXCH(5) address externals- 
Declare RQAIEX(5) address externals- 
Declare A$D$EXCH(5) address externals- 
Declare CONSTANT$LOCKOUT$EXCH (5) address external; 
Declare CRT$STATUS$EXCH(5) address external; 

Declare ALARM$MSG structure (MSG$HDR) ; 

Declare CONVERT a i$nisg; 

/* This term is used to convey initial temperatures */ 

33 1 Declare CAL$TEMP based MSG$PTR structure ( 

MSG$HDRs 

CAL address ) ; 

34 1 RQWAIT: 
Procedure (EXCHsMESSAGE) address external; 
Declare (EXCHs MESSAGE) address; 

en6 RQWAIT; 
RQSEND: 

Procedure (EXCHs MESSAGE) external; 
Declare (EXCH^ MESSAGE) address; 

end RQSEND; 
RQACPT: 

Procedure (EXCH) address external; 

Declare EXCH address; 
end RQACPT; 

Declare OVEN$IN$TOL (4 ) byte data ( 

01Hs(?2Hs04H,08H ) ; 
Declare OVEN$CAUTION (4 ) byte data ( 

10Hs2fHs4 0Hs80H ) ; 

Declare OVEN$DANGER (4) byte data ( 
01Hs02Hs04Hs08H ); 

Declare OVEN$ON$MASK (4 ) byte data { 
01Hs02Hs04H,08H ) ; 

Declare OVEN$HEATER (4 ) byte data ( 
10Hs20H,40Hs80H ); 

Declare 0VEN$RUN(4) byte data ( 
10Hs20Hs40Hs80H ) ; 

Declare OFFSET (4) address; 

Declare TABLE (255) address data ( 

200s 20 Is 20 2s 20 3 s 204 s 20 5s 206, 207s 208s 209, 
209s^l0,211s212s 21 3s 214 s 215s 21 6s 217 ,21 8, 
219 s 220 s 22 Is 222 s 223, 224 s 225 s 226 s 227, 228 s 
2 29, 23 0, 231 s 23 2s 23 3s 23 5, 236, 237, 238, 239, 
24 s 24 1 s 24 3 s 24 4 s 24 5 s 24 7 , 24 8 s 24 9,250, 251 , 
252,254, 256 , 25'^ , 258 , 259 , 260 , 261 , 263 , 265 , 
266, 267, 268, 269, 270, 271s 27 3s 274s 276s 278s 
279 s 280 s 28 2 s 284 s 28 5 s 287 , 288 , 289 , 290 , 291 , 
293 ,29 5, 29 6, 298, 299s 300s 302s 304s 30 5, 307, 
3 08, 309, 31 0,31 2s 314s 31 6s 31 8s 320, 3 22, 324, 
326,328,330,332,3 34,336,338,340,342,34 4, 
34 6, 34 8 s 350 , 352 , 354 , 356 , 358 , 360, 362 , 364 , 
36 6, 368, 370, 372 s 374, 376, 378, 380 s 38 2, 38 5, 
308, 390, 392, 39 5 s 398, ^00, '1 02 s 40 5, 4 07 s 41 s 
/?12s415s418s^20s42 3s426s4 28s430,^33,436, 
4 3 9,441,444,^4'' , ^51,454, 457,460,463,^66, 



35 


2 


36 


2 


37 


1 


38 


2 


39 




40 




41 




42 




43 




^A 




45 




46 




47 




48 




49 




50 
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52 


2 


53 


2 


5^ 


2 


55 


2 


56 


2 


57 


2 


58 


2 


59 


2 


6C 


2 



62 


3 


63 


3 


6A 


3 


65 


3 


66 


3 


67 


3 


6 9 


A 


7 


4 


71 


5 


72 


5 


7 3 


A 


7^ 


5 


75 


5 


76 


A 


77 


3 


78 


4 


80 


A 


81 


A 




/* Initialization of control task */ 
51 1 CONTROL$TASK: 

Procedure public; 

Output(235)=81H; 
CONVERT.BASE$PTR = 0F7r«0H; 
CONVERT. LENGTH=21 ; 
CONVERT. TYPE =ATSQS ; 
CONVERT. RES PSE>: = .A$D$EXCH ; 
CON VERT. CHANNEL$GAIN=0 ; 
CONVERT. ARRAY$PTR=. TEMP; 
CONVERT. C0UNT=4; 
Do forever; 
/* Wait for one second to elapse */ 
61 3 MSG$PTR=ROWAIT ( . DUKiMY$EXCH, 2(^) ; 

/* Bring in data from switches */ 

BLOCK0=NOT INPUT (234); 
/* Lockout temperature storage areas for update */ 

LOCKOUT^RQWAIT ( . TEMP$LOCKOUT$EXCH , C ) ; 
/* Get raw data from analog converter */ 
Call RQSEND ( .R'QAIEX, .CONVERT) ; 
MSG$PTR=ROWAIT(.A$D$EXCH,0) ; 
/* Temperature calibrate procedure */ 
MSG$PTR=RQACPT(.TEMP$CALIBRATE) ; 
If |V|SG$PTR <> 
then do; 
k = 0; 

Do while (TABLE ( k) OCALTEMP.CAL AND 
k<255); 
k = k4-l; 
end; 
Do n=0 to 3; 

OFE^SET(n) = (TEMP(n)/IS)-k; 
end; 
end; 
/* Convert data into engineering units */ 
Do n=0 to 3; 

If ( (TEMP(n)/16)-0FFBET{n) )>255 
then TEMP(n)=0; 

else TEMP(n)=TABLE( (TEMP(n)/16)-0FFSET(n) ) ; 
end; 

/* Release lockout of temperatures */ 
82 3 Call RQSEND (. TEMP$LOCKOUT$EXCI-l, LOCKOUT) ; 

/* Compute average temperature */ 
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83 


3 
4 


85 


A 


87 


5 


88 


n, 


89 
9 
91 


5 
4 
5 


92 


5 


93 


5 


9^ 
95 


4 
4 


96 

97 


4 
4 


99 

100 


5 
5 



Do n=0 to 3; 

T$AVERAGE(n)= (T$LAST (n) 4-TEMP (n) )/2; 
/* Project temperatures into the future */ 
If T$AVERAGE(n)>=T$LAST$AVERAGE(n) 
then do; 

T$t5 {n)=( (T$AVERAGE(n)-T$LAST$AVERAGE(n) )*5) 

+T$LAST$AVERAGE (n) ; 
T$tl0(n)=( (T$AVERAGE (n) -T$LAST$ AVERAGE (n) )*10) 
+T $ LAST f> AVER AGE (n) ; 
end; 

else do; 

TStS (n) =T$LAST$AVERAGE (n) - ( (T$.LAST$AVERAGE (n) 

-T$AVERAGE(n) )*5) ; 
T$tl0 (n) =T$LA5i;T$AVERAGE r n) - ( (T$l.AST^AVERAGE (n) 
-T$AVERAGE(n) )*10); ^ 
end; 
/* Update stored data */ 

T$LA.STJ^AVERAGE(n)=T$AVERAGE(n) ; 
T$LAST(n)=TEMP(n) ; 
/* Test for active oven */ 

MSG$PTR=RQWAIT ( .CONSTANT$LOCKOUT$EXCH, ) ; 
If (((BLOCK0 AND OVEN$ON$MASK (n) ) <>0 ) 
AND (TEMP(n)<>0)) 
then do; 

STATUS (n) =7; 

BLOCK2=BLOCK2 OR OVEN$RUN(n); 
/* Test for an intolerance condition */ 
101 5 If SETPOINT(n) -TOLERANCE (n) < TEMP(n) AMD 

SETPOINT(n)+TOLERANCE(n) > TEMP(n) 

then do; 

103 6 STATUS (n) =7; 

104 6 BL0CK1=BL0CK1 OR OVEN$IN$TOL (n) ; 

105 6 end; 

106 5 else BL0CKI=BL0CK1 AND NOT OVEN$IN$TOL (n) ; 

/* Test for a caution condition */ 

107 5 If SETPOINT(n) -TOLERANCE (n) > T$t5(n) OR 

SETPOINT(n)+TOLERANCE(n) < T$t5(n) 
then do; 

109 6 STATUS (n) =14; 

110 6 BL0CK1=BL0CK1 OR OVEN$CAUTION (n) ; 

111 6 end; 

112 5 else BL0CK1=BL0CK1 AND MOT 0VEN$CAUT10N (n) ; 

/* Test for a danger condi^ion */ 

113 5 If SETPOINT(n) -TOLERANCE (n) > TEMP(n) OR 

SETPOI.NT(n)+TOLERANCE(n) < TEMP(n) 
then do; 

115 6 STATUS (n) =21; 

116 6 BLOCK2=BLOCK2 OR OVEN$DANGER (n) ; 

117 6 end; 

118 5 else BLOCK2=BLOCK2 AND NOT OVEN$DANGER (n) ; 

/* Handle control of heater elements */ 

119 5 If SETPOINT(n) > T$tl0(n) 

then BLOCK3=BLOCK3 OR OVEN$HEATER (n) ; 
else ELOCK3=BLOCK3 AND NOT OVENSHEATER f n) ; 
end; 
else do; 
/* Turn everythinq off when operator shuts off oven */ 
BL0CK1=BL0CK1 AND NOT GVEN$IN$TOL (n) ; 
BL0CK1=BL0CK1 AND NOT OVEN$CAUTION (n) ; 
SLOCK3=BLOCK3 AND NOT OVEN$HEATER (n) ; 
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BLOCK2=BLOCK2 AND MOT OVEN$DANGER (n) ; 

BLOCK2=BLCCK2 AND NOT OVEN$RUN(n); 

STATUS (n)=0; 
end ; 

Call RQSEND(.CONSTANT$LOCKOUT$EXCH,MSG$PTR) ; 
end ; 

/* Output data to real world */ 

OUTPUT (232) =BL0CK1; 

OUTPUT (233) =B LOCK 2 ; 

OUTPUT ( 234 )=RL0CK3; 
end; 

end CONTROL$TASK; 
end CONTROL$TASK$MODULE; 

MODULE INFORMATION: 

CODE AREA SIZE = ^946H 2374D 
VARIABLE AREA SIZE = 0054H BAD 
MAXIMUM STACK SIZE = 0006H 6D 
235 LINES READ 
PROGRAM ERROR (S) 

END OF PL/M-80 COMPILATION 



$TITLE('CRT PARAMETER TASK') 
/•*********•*******••*■************************* 

* This task is used to examine and update the * 

* temperature setpoints and tolerances for * 

* each of the four ovens. * 
********************************* *****^****-****/ 

UPDATE^TASK: 
Do; 

$ Incl ude ( : F0 : COMMON . ELT ) 

TRUE LITERALLY 'PFFH'; 
FALSE LITERALLY ' 00H ' ; 
BOOLEAN LITERALLY 'BYTE'; 
FOREVER LITERALLY 'WHILE 1*; 
(:F0:MSGTYP.ELT) 
1 = DECLARE DATA$TYPE LITERALLY '0', 
INTSTYPE LITERALLY '1\ 
MISSED$INT$TYPE LITERALLY '2', 
TIME$OUT$TYPE LITERALLY '3*, 
FS$REQ$TYPE LITERALLY 'A*, 
UC$REQ$TYPE LITERALLY '5\ 
FS$NAK$TyPE LITERALLY '6', 
CNTRL$C$TYPE LITERALLY '7', 
READ^TYPE LfTERALLY '8', 
CLR$RD$TYPE LITERALLY •9*, 
LAST$RD^-TYPE LITERALLY M0', 
ALARM^TYPE LITERALLY '11*, 
WRITE$TYPE LITERALLY M2'; 

$Include ( :F0 :MSG. ELT) 
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DECLARE 
$Include 
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7 1 = DECLARE MSGSHDR LITERALLY * 

LINK ADDRESS, 
LENGTH ADDRESS, 
TYPE BYTE, 
HOME$EX ADDRESS, 
RESP$EX ADDRESS'; 

8 1= DECLARE MSG$t)ESCRIPTOR LITERALLY ' STRUCTURE ( 

MSG$HDR, 

REMAINDER (1 ) BYTE) •; 
$ Include ( :F0 iTHMSG. ELT) 

9 1= DECLARE TH$MSG LITERALLY 'STRUCTURE ( 

MSGHDR, 

STATUS ADDRESS, 
BUFFER$ADR ADDRESS, 
COUNT ADDRESS, 
ACTUAL ADDRESS, 
REMAINDER (128) BYTE)'; 
10 1 = DECLARE MIN$TH$MSG$LENGTH LITERALLY '17'; 
$Include ( : F0:CHAR. ELT) 

/* SPECIAL ASCII CHARACTERS */ 



11 1 



DECLARE 
NULL 

CONTROL$C 
CONTROL$E 
BELL 
TAB 
LF 
VT 
FF 
CR 

CONTROL$P 
CONTROL$Q 
CONTROL$R 
CONTROL$S 
CONTROL$X 
CONTROL$Z 
ESC 
QUOTE 
LCA 
LCZ 
RUBOUT 



literally 
literally 
litE:rally 
literally 
literally 
literally 
literally 
litejrally 
literally 
literally 
literally 
literally 
literally 
literally 
literally 

LITERALLY 
LITERALLY 
LITERALLY 
LITERALLY 
LITERALLY 



'0PH' 
'03H' 
'05H' 
'07H' 
'09H' 
' 0AH • 
^0BH' 
• 0CH • 
'0DH' 
'10H' 
'IIH' 
'12H' 
'13H' 
'18H' 
•lAH' 
'IBH' 
•22H' 
'61H' 
'7AH' 
•7FH' 



1 2 1 

13 2 

1 4 2 

15 1 

16 2 



^Include (: F0 -.SYNCH. EXT) 
RQSEND: 

PROCEDURE 
DECLARE 



( EXCHANGE $PCINTER, MESSAGE $POINTER) EXTERNAL; 
(EXCHANGE $POINTER,MESSAGE$POINTER) ADDRESS; 



END RQSEND; 



RQWAIT: 

PROCEDURE 
DECLARE 



(EXCHANGE$POINTER, DELAY) 
(EXCHANGE $POINTER, DELAY) 



ADDRESS EXTERNAL; 
ADDRESS; 
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17 2 = END RQWAIT; 

10 ] = RQACPT: 

PROCEDURE (EXCHANGE^POINT^JR) ADDRESS EXTERNAL; 
1.9 2 = DECLARE EXCHANGESPOINTER ADDRESS; 

END RQACPT; 

RQISND: 

PROCEDURE (IED$PTR) EXTERNAL; 
DECLARE lEDJ^PTR ADDRESS; 

END RQISND; 
Declare TEMP$CALIBRATE (5 ) address external; 
Declare UPDATE$EXCH (5) address external; 
Declare CRT$STATUS$EXCH (5) address external; 
Declare C0MP$EXCH(5) address external; 
Declare CCNSTANT$LOCKOUT$EXCH (5 ) address external; 
Declare RQ0UTXf5) address external; 
Declare RQINPX(5) address external; 
Declare WORDS$EXCH (5) address external; 
Declare SETP0INT(4) address external; 
Declare TOLERANCE ( 'I ) address external; 
Declare BUFB^ER2 address; 
Declare MSG$PTR address; 
Declare MSG structure ( 

MSG$HDR, 

STATUS address, 

BUFFER$PTR address, 

COUNT address, 

ACTUAL address ) ; 

37 1 Declare CAL$TEMP structure f 

MSG^HDR, 

CAL address ) ; 

38 J Declare UPD$MSG address; 

39 1 Declare ENERGIZE based UPD$MSG structure ( 

MSG$HDR, 
STATUS address, 
BUFFER$PTR address, 
COUNT address, 
ACTUAL address ) ; 

40 1 Declare ENABL£$MSG structure ( 

MSG$HDR ); 
Declare BUFFER(80) byte; 
Declare OVEN byte; 
DEC$REP: 

Procedure (SOURCE, TARGET) external; 
Declare (SOURCE, TARGET) address; 
end DECf^REP; 
ASC$2$BINARY: 

Procedure (SOURCE, TARGET, SIZE) byte external; 
Declare (SOURCE, TARGET) address; 
Declare SIZE byte; 
end ASC$2$BINARY; 

Declare MSG$1 (20) byte data ( 
ESC, 'E* , 'ENTER OVEN NUMBER-*); 
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51 1 Declare MSG$2(28) byte data ( 

CR.LF, 
•ENTER NEW SETPOINT-', 

52 1 Declare MSG$3(29) byte data ( 

CR.LF, 

•ENTER NEW TOLERANCE- •, 
•XXXX.X-* ); 

53 1 Declare CALMSG(12) byte data ( 

•TEMPERATURE-* ); 

54 1 Declare MSG$4 (62) byte data ( 

CR,LF, 

• (STATUS- (S) , PARAMETERS- (P) , CALIBRATE- (C) )• , 
CR,LF, 

•ENTER REQUEST-' ) ; 

55 1 Declare WAIT literally •MSG$PTR=*; 

56 1 Declare FOR literally 'RQWAIT'; 

57 1 Declare START literally 'CALL*; 

58 1 Declare TASK literally 'RQSEND*; 

59 1 UPDATE: 

Procedure public; 

/* Initialize task at start-up time */ 

60 2 Do forever; 

61 3 WSG.RESP$EX=.COMP$EXCH; 

/* Wait for request to enter task */ 

62 3 UPD$MSG=RQWAIT ( . UPDATE$EXCH, 0) ; 

/* Get desired oven number from operator */ 

63 3 RQST$OVEN: 

MSG.BUFFER$PTR=.MSG$1 ; 

MSG.TYPE=WRITE$TYPE; 

MSG. COUNT=20; 

Start task ( .RQOUTX, .MSG) ; 

Wait for ( .COMP$EXCH, 0) ; 
/* ...Input new number */ 

MSG.BUFFER$PTR=. BUFFER; 

MSG.COUNT=255; 

MSG.TYPE=CLR$RD$TYPE; 

Start task ( .RQINPX, .MSG) ; 

Wait for ( .COMP$EXCH, f) ) ; 

OVEN= (BUFFER (0) AND 07H)-I; 

If OVEN >3 then go$to RQST$OVEN; 
/* Display request and current setpoint */ 
76 3 GET$TEMP: 

Call move (28 , .MSG$2, .BUFFER) ; 

Call DEC$REP (. SETPOINT (oven) ,. BUFFER+21 ) ; 
MSG.TYPE=WRITE$TYPE; 

MSG.COUNT=28; 

Start task ( .RQOUTX, .MSG ) ; 

Wait for ( .COMP$EXCH, 0) ; 
/* ... Input new setpoint */ 

MSG . TYPE=CLR$RD$TYPE ; 

Start task ( .RQINPX, .MSG ) ; 

Wait for ( .COMP$EXCH,0) ; 

If ASC$2$BINARY (. BUFFER, .BUFFER2,1)=0 OR BUFFER2 > 700 

then go$to GET$TEMP; 
87 3 If BUFFER2 <> 

then do; 

Wait for ( .CONSTANT$LOCKOUT$EXCH,0); 

SETPOINT (oven) =BUFFER2; 

Start task ( .CONSTANT$LOCKOUT$EXCH,MSG$t^TR) ; 
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92 4 end; 

/* Display request and current tolerance */ 

93 3 GET$TOL: 

Call move (29 , .MSG$3, .BUFFER) ; 
Call DEC$REP (.TOLERANCE(oven) ,.BUFFER422) ; 
MSG.TYPE=WRITE$TYPE; 
|viSG.COUNT = 29; 

Start task ( .RQOUTX, .MSG) ; 
Wait for ( •COMP$EXCH, 0) ; 
/* ...Input nev; tolerance */ 
|V|SG.TYPE=CLR$RD$TYPE; 

Start task ( .RQllMPX, .MSG ) ; 
Wait for ( .COMPSEXCH, ) ; 

If ASC$2$BINARY (. BUFFER,. BUFFER2, 1)=0 OR BUFFER2 > 700 
then go$to GET$TOL; 
104 3 If BUFFER2 <> 

then do; 

Wait for ( .CONSTAMT$LOCKOUT$EXCH,0) ; 

TOLERANCE (oven) =BUFFER2; 

Start task ( .C0NSTANT$L0CK0UT$EXCH,MSG$PTR) ; 

end; 

/* Ask operator if he is finished */ 
110 3 REQ^NEXT: 

|V!SG.TYPE=WRITE$TYPE; 
MSG.COUNT=62; 
MSG.BUFFER$PTR=.MSG$4; 
Start task ( .RQOUTX, .MSG ) ; 
Wait for ( .COMP$EXCH, 0) ; 
/* ...Get his response */ 

MSG.TYPE=CLR$RD$TYPE; 

|vi.SG.BUFFER$PTR = . BUFFER; 

Start task ( .RQINPX, .MSG) ; 

Wait for ( .COMP$EXCH, 0) ; 

If (BUFFER(0) O'S* AND BUFFER(0) O'P' 

AMD BUFFER(0) <> 'C ) 
then go$to REQ$NEXT; 
If BUFFER(0)='P' 

then go$to RQST$OVEN; 
If BUFFER(0)=»C* 
then do; 

GET$CAL: 

MSG. TYPE=WRITE$TYPE ; 

MSG.C0UNT=12; 

MSG . BUFFER$PTR=. CALMSG ; 

Start task ( .RQOUTX, .MSG ) ; 

Wait for ( .C0MP$EXCH, 0) ; 

MSG. TYPE =CLR$RDSTYPE; 

MSG. DUFFER$PTR=. BUFFER; 

Start task ( .RQIWPX, .MSG ) ; 

Wait for ( .C0MP$EXCH, 0) ; 

If ASC$2$BINARY(. BUFFER,. BUFFER2,1) =0 
OR BUFFER2>350 OR BUFFER2<200 

then go$to GET$CAL; 

CAL$TEMP.CAL^BUFFER2; 

Call RQSEND ( .TEMP$CALIBRATE, .CAL$TEMP) ; 
en6', 
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MODULE INFORMATION: 

CODE AREA SIZE = 03C3H 963D 
VARIABLE AREA SIZE = 007CH 12^D 
MAXIMUM STACK SIZE = 0004H AD 
264 LINES READ 
?■ PROGRAM ERROR (S) 

END OF PL/M-8 COMPILATION 

139 3 ENERGIZE. TYPE=100; 

140 3 Start task ( . CRT$STATUS$EXCH, UPD^MSG ) ; 

141 3 end; 

142 2 end UPDATE; 

14 3 1 end UPDATE $TASK; 



$TITLE(*CRT UPDATE TASK') 
/****************•**•**************************** 

* This task is utilized to update the CRT ter- * 

* minal display with the current operating par- * 

* ameters. It will be entered upon sytem start- * 

* up, upon operator request, or when a problem * 

* exists with any of the activated ovens. * 

CRT$DATA$MODULE: 

Do; 

$INCLUDE(:F0: SYNCH. EXT) 

RQSEND: 

procedure (exchange$pointer, message j^^pointer) external; 
declare (exchange$pointer,message$pointer) address; 

end rqsend; 
rqv;ait: 

PROCEDURE (EXCHANGE$P0INTER, DELAY) ADDRESS EXTERNAL; 
DECLARE (EXCHANGE^POINTER, DELAY) ADDRESS; 

END RQWAIT; 

RQACPT: 

PROCEDURE (EXCHANGESPOINTER) ADDRESS EXTERNAL; 
DECLARE EXCHANGE$POINTER ADDRESS; 

END RQACPT; 

RQISND: 

PROCEDURE (IED$PTR) EXTERNAL; 
DECLARE IED$PTR ADDRESS; 

END RQISND; 
^INCLUDE (:F0:MSGTYP.ELT) 
DECLARE DATA^TYPE LITERALLY '0*, 
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INT$TYPE LITERALLY '1', 
M1SSED$INT$TYPE LITERALLY '2\ 
TIME^OUT^TYPE LITERALLY '3*, 
FS$REQ$TYPE LITERALLY M*, 
UC$REQ$TYPE LITERALLY '5', 
FS$NAK$TYPE LITERALLY '6^ 
CNTRL$C$TYPE LITERALLY '7', 
READ$TYPE LITERALLY *S', 
CLR$RD$TYPE LITERALLY '9', 
LAPT$RD$TYPE LITERALLY 'IP', 
ALARM$TYPE LITERALLY '11 \ 
WRITE$TYPE LITERALLY •12'; 
$INCLUDE (:F0:EXCH.ELT) 
15 1 = DECLARE EXCHANGE$DESCRIPTOR LITERALLY 'STRUCTURE ( 
MESSAGE$HEAD ADDREGS, 
MESSAGE$TAIL ADDRESS, 
TASK$HEAD ADDRESS, 
TASK$TAIL ADDRESS, 
EXCHANGE^LINK ADDRESS)'; 
$INCLUDE ( :F0: COMMON. ELT) 
DECLARE TRUE LITERALLY ' OFFH ' ; 
DECLARE FALSE LITERALLY •00H'; 
DECLARE BOOLEAN LITERALLY 'BYTE'; 
DECLARE FOREVER LITERALLY 'WHILE 1'; 
$INCLUDE ( :F0:MSG.ELT) 

20 1 = DECLARE MSG$HDR LITERALLY ' 

LINK ADDRESS, 
LENGTH ADDRESS, 
TYPE BYTE, 
HOME$EX ADDRESS, 
RESP$EX ADDRESS'; 

21 1 = DECLARE MSG$DESCRIPTOR LITERALLY 'STRUCTURE ( 

MSG$HDR, 

REMAINDER (1) BYTE) '; 
s^INCLUDE (:F0:CHAR.ELT) 



22 1 = 



I'S 


1 


17 


1 


18 


1 


19 


1 



/* SPECIAL ASCII CHARACTERS */ 


DECLARE 






NULL 


LITERALLY 


'00H' 


CONTROL^C 


LITERALLY 


'03H' 


CONTROL$E 


LITERALLY 


'05H' 


BELL 


LITERALLY 


'07H' 


TAB 


LITERALLY 


'09H' 


LF 


LITERALLY 


•PAH' 


VT 


LITERALLY 


'0BH' 


FF 


LITERALLY 


•0CH' 


CR 


LITERALLY 


•0DH' 


CC)NTROL$P 


LITERALLY 


•10H' 


CONTHOL$Q 


LITERALLY 


'IIH' 


CONTROL$R 


LITERALLY 


' 1 2H ' 


CONTROL$S 


LITERALLY 


'i3H' 


CONTROL$X 


LITERALLY 


•18H' 


CONTROLSZ 


LITERALLY 


• lAH ' 


ESC 


LITERALLY 


•IBH' 


QUOTE 


LITERALLY 


•22H' 
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LCA LITERALLY •61H' , 

LCZ LITERALLY * 7AH * , 

RUBOUT LITERALLY ' 7FH * ; 

$INCLUDE (:F(?:THMSG.ELT) 

23 1 = DECLARE TH$MSG LITERALLY 'STRUCTURE ( 

MSGHDR, 

STATUS ADDRESS, 
BUFFER$ADR ADDRESS, 
COUNT ADDRESS, 
ACTUAL ADDRESS, 
REMAINDER(128) BYTE)'; 

24 1 = DECLARE MIN$TH$MSG$LENGTH LITERALLY '17' 

25 I Declare HOME literally '1BH,48H'; 

26 1 Declare L1$IMAGE(90) byte data ( 

Home,Lf ,Lf ,Lf ,Lf ,Lf , 
'TEMPERATURE ', 



'DEGREES C. ' ) ; 
27 1 Declare L2$IMAGE(92) byte data ( 
Home , Lf , Lf , Lf , Lf , Lf , Lf , Lf , 
•SETPOINT ', 



•DEGREES C. ' ) ; 
28 1 Declare L3$IMAGE(94) byte data ( 

Home , Lf , Lf , Lf , Lf , Lf , Lf , Lf , Lf , Lf , 
'TOLERANCE ', 



•DEGREES C ) ; 

29 1 Declare L^$IMAGE(75) byte data ( 

Home , Lf , Lf , Lf , Lf , Lf , Lf , Lf , Lf , Lf , Lf , Lf , 

'STATUS ', 

' OFF ' , 

• OFF ' , 

' OFF • , 

' OFF ' ); 

30 1 Declare CF^T^HDR (168) byte data ( 

1BH,45H,' 

'OVEN STATUS DISPLAY', 
Cr,Lf,Lf,' ', 

'0VEN~1 ' , 
'0VEN~2 ', 
•0VEN~3 ', 
'0yEN~4', 
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Cr,Lf ,Lf:,Lf ,Lf ,Lf ,Lf ,Lf ,Lf ,Lf ,Lf ,Lf ,Lf ,Lf ,Lf ,Lf ,Lf ,Lf ,Lf ,Lf , 

'TYPE ESCAPK TO ADJUST SETPOINTS' ); 
1 Declare BRLLSC^) byte data ( 

Bell, Bel] , Bell .Bell ); 
1 Declare MESSAGES (35) byte data ( 

' OFF • , 

• OK • , 
•CAUTION* , 

• ALARM • , 

• ); 

1 Declare DISPLAY$PTR1 (4 ) address data ( 

.WORK$BUFF+23, 

.WORK$BUFF4-36, 

.WORK$BUFF+49, 

.WORK$BUFF+62 ) ; 
1 Declare DISPLAY$PTR2 M ) address data ( 

.WORK$BUFF+2 5, 

.W0RK$BUFF+3a, 

.W0RK$BUFF+51, 

.WORKJ^^BUFF+64 ); 
1 Declare DISPLAY$PTR3 (4 ) address data ( 

.WORK$BUFF'f-27, 

.WORK$BUFF+40, 

.WORK$BUFF+53, 

.W0RK$BUFF-f66 ) ; 
1 Declare DISPLAY$PTR4 (4 ) address data ( 

.WORKBUFF+SC^, 

.WORKBUFF+4 3, 

.W0RKBUFF4-56, 

.W0RKBUFF+rS9 ); 
1 Declare MSG$PTR address; 
1 Declare MSG based MSG$PTR structure ( 

MSG^HDR, 

COUNT address ) ; 
1 Declare STARTER (3) structure ( 

MSG^HDR ); 
1 Declare READ structure ( 

MSG$HDR, 

STATUS address, 

BUFFER$PTR address, 

COUNT address, 

ACTUAL address ) ; 
1 Declare DISPLAY$TEMP (4 ) structure ( 

UPPER address, 

LOWER address ) ; 
1 Declare DISPLAY$SET (4) structure ( 

LOWER address, 

UPPER address ) ; 
1 Declare DISPLAY$TOL (4) structure ( 

LOWER address, 

UPPER address ) ; 
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44 1 Declare 0VEN$0M(4) byte data ( 

01H,02H,04H,08H ); 

45 1 Declare OVEN$CAUTION (4 ) byte data ( 

10H,20H,4rH,80H ) ; 

46 1 Declare CRT structure ( 

MSG$HDR, 

STATUS address, 

BUFFERSPTR address, 

COUNT address, 

ACTUAL address ) ; 
Declare CRTLOCK structure (MSG$HDR) ; 
Declare CRT$DISPLAY$LOCK (5) address external; 
Declare TEMP$LOCKOUT$EXCH (5) address external; 
Declare CONSTANT$LOCKOUT$EXCH (5) address external; 
Declare CRT$EXCH(5) address external; 
Declare CRT$STATUS$EXCH (5) address external; 
Declare DUMMY^EXCH (5) address external; 
Declare READ$BUFFER$EXCH (5) address external; 
Declare UPDATE^EXCH (5) address external; 
Declare R0INPX(5) address external: 
Declare RQ0UTX{5) address external; 
Declare RQWAKE(5) address external; 
Declare RQL7EX(5) address external; 
Declare RQL6EX(5) address external; 
Declare R0DBUG(5) address external; 
Declare RQALRM(5) address external; 
Declare TEMP (4) address external; 
Declare DISP$TEMP(4) address; 
Declare SETP0INT(4) address external; 
Declare DISP$SETPNT (4 ) address; 
Declare T0LERANCE(4) address external; 
Declare DISP$T0L(4) address; 
Declare STATUS (4) byte external; 
Declare DISP$STAT(4) byte; 
Declare ( BLOCKl , BL0CK2) byte external; 
Declare WORK$BUFF (1 70) byte; 
Declare BUFFER$A(70) byte; 
Declare (CHANGE ,n , ALARM, NEW, BLANKER) byte; 

Declare START literally 'call'; 
Declare TASK literally » rqsend ' ; 
Declare WAIT literally *msgSptr=*; 
Declare For literally *rqwait'; 
DEC^REP: 

Procedure (SOURCE, TARGET) external; 

Declare (SOURCE, TARGET) address; 
end DEC$REP; 
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8 2 1 CRT$DATA$TASK: 

ProcecJure public; 

/* Initialize system at start-up time */ 

Start task ( .TEMP$LOCKOUT$EXCH, .STARTER (0) ) ; 
Start task ( .CONSTANT$LOCKOUT$EXCH, .STARTER(l) ) ; 
STARTER (2) .TYPE=100; 

Start task ( .CRT$STATUS$EXCH, . STARTER (2) ) ; 
CRT.RESP$EX=.CRT$EXCH; 
/* Perform main CRT wait */ 
Do forever; 

Wr?it for ( .DUMMy$EXCH, 10) ; 
Wait for ( .CRT$STATUS$EXCH, 0) ; 
If MSG.TyPE=255 
then ALARM=1; 
93 3 else ALARM=0; 

/* Output heading */ 

If (MSG.TYPE=100 OR MSG • TYPE=255 ) 
then do; 

If ALARM=0 

then ca.U RQSEND ( .CRT$DISPLAY$LOCI<, .CRTLOCK) ; 
CRT.TYPE=WRITE$TYPE; 
CRT.COUNT=167; 
CRT. BUFFER$PTR=.WORK$BUFB^• 
R£AD.TYPE=CLR$RD$TYPE; 
READ.COUNT=2 55; 

READ.RESP.^EX = .READ$BUFFER$EXCH; 
READ.BUFFER$PTR=.BUFFERA; 
If ALARM=0 

then start task ( .RQINPX, . READ) ; 
Call move (82, .CRT$HDR, .WORK$BUFF) ; 
Call move (86, .CRT^HDR+R2, .WORK$BUFF+82) ; 
Start task ( .RQOUTX, .CRT) ; 
Wait for (.CRT$EXCH,0); 
NEW=1; 
end; 
/* Test for change in temperature of any oven */ 
CHANGE=0; 

Wait for ( .TEMPSL0CK0UT$EXCH, 0) ; 
Do n=0 to 3; 

If TEMP(n)<>DISP$TE(^^P(n) 
then CHANGE=1; 
end; 

Call move (8, .TEMP, .DISP$TEMP) ; 
Start task ( .TEMP$LOCKOUT$EXCH,MSG$PTR) ; 
/* When a change exists build new line */ 
121 3 If CHANGE OR NEW 

then do; 

Call move (90 , . Ll$I|v!AGE, .WGRKi^BUFF) ; 
Do n=0 to 3; 

Cal-1 DEC$REP(.DISP$TEMP(n) , DISPLAY^PTRl (n) ) ; 
end; 
/* Output new temperature line to CRT */ 
CRT. TYPE =WRTTE$TYPE; 
CRT.COUNT=87; 
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129 4 Start task ( .RQOUTX, .CRT) ; 

130 A Wait for ( .CRT$EXCH, 0) ; 

131 4 end; 

/* Test for change in oven setpoints */ 

132 3 CHANGE=:0; 

133 3 Wait for ( .C0NSTANT$L0CK0UT:?EXCH, 0) ; 

134 3 Do n=0 to 3; 

135 4 If SETPOINT(n)<>DISP$vSETPNT(n) 

then CHANGE=1; 

137 4 end; 

138 3 Cell] move (8 , . SETPOINT, . DISP$SETPNT) ; 

139 3 Start task ( .CONSTANT$LOCKOUT$EXCH,MSG$PTR) ; 

/* Build new line when a change v/as detected */ 
14 3 If CHANGE OR NEW 

then do; 

Call move (92, •L2$IMAGE, .WORKBUFF) ; 
Do n=0 to 3; 

Call DEC$REP(.DISP$SETPNT(n) , DISPLAy$PTR2 (n) ); 
end; 
/* Output set point line */ 

CRT.TYPE=WRITE$TYPE; 
CRT.COUNT=89; 
CRT. BUFFEH1*5PTR = .WCRKBUFF; 
Start task ( .RQOUTX, .CRT) ; 
Wait for ( .CRT^EXCH, 0) ; 
end; 
/* Test for change in tolerance ] ine */ 
CHANGE=0; 

Wait for ( .CONSTANT$LOCKOUT$EXCH, 0) ; 
Do n=0 to 3; 

If TOLERANCE (n)<>DTSP$TOL(n) 
then CHANGE=1; 
end; 

Call move ( 8 , .TOLERANCE, .DISP$TOL) ; 
Start task ( .CONSTANT$LOCKOUT^EXCIJ,MSG$PTR) ; 
/* When change is found, build new line */ 
160 3 If CHANGE OR NEW 

then do; 

Call move (94 , . L3$IMAGE , .WORK$BUFF) ; 
Do n=0 to 3; 

Call DEC$REP(.DISP$TOL(n) ,DISPLAY$PTR3 (n) ) ; 
end; 
/* Output tolerance line */ 

CRT. TYPE =WRITE$TYPE; 

CRT.C0UNT=91; 
CRT.BUFFER$PTR=.WORKBUFF; 

Start task ( .RQOUTX, .CRT) ; 

Wait for (.CRT$EXCH,0) ; 
end; 
/* Build status message */ 
CHANG E=0; 

Wait for ( .CONSTANT$LOCKOUT$EXCH, ) ; 
Do n=0 to 3; 

If STATUS (n)<>DISP$STAT(n) 

then CHANGE=1; 
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177 4 en6; 

178 3 Call move ( 4 ,. STATUS , .DISP$STAT) ; 

179 3 Start task ( .CONSTANT$LOCKOUT$EXCH,MSG$PTR) ; 

/* Output to display */ 
18(^ 3 If CHANGE OR NEW 

then do; 

Call move (75, . L4IMACE, .WORK$BUFF) ; 
Do n=P to 3; 

Call move (7, .MESSAGES+DISP$STAT (n) ,DISPLAY$PTR4 ( 
n)); 

end ; 

CRT.COUNT=76; 

Start task ( , RQOUTX, .CRT) ; 
Wait for ( .CRT$EXCH, (?i ) ; 
end; 
/* test for request to exit this mode */ 
MSG$PTR=RQACPT ( .READ$BUBTER?EXCH ) ; 
If ALARFi=0 
then do; 
193 4 If (MSG$PTR <> and BUFBERA(0) = IBH) 

then do; 

MSC$PTR=ROWAIT ( .CRT$DISPLAY$LOCK, 0) ; 
start task ( .UPDATE$EXCH,MSG$PTR) ; 
end; 
else do; 

If MSG$PTR=0 

then STARTER(2) .TYPE=200; 
else STARTER (2) .TYPE=T0P; 

Start task ( .CRT$STATUS$EXCH, . STARTER (2 )) ; 
NP:":W=0; 
end; 
end; 
end; 
end CRT$DATA$TASK; 
end CRT$DATA$MODULE; 



MODULE INFORMATION: 

CODE AREA SIZE = 0720H 1824D 
VARIABLE AREA SIZE = R3 89H 393D 
MAXIMUM STACK SIZE = 0004H 4D 
3P8 LINES READ 
PROGRAM ERROR (S) 
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END OF PL/M-80 COMPILATION 
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$TITLE( 'ASCII STRING TO FIXED BINARY') 
/***************************************************• 

* This program converts an ASCII string into a fix- * 

* ed point binary number. The fixed decimal point * 

* is determined by the parameter passed in SIZE. * 

ASC$2$BINARy$iviODULE: 

Do ; 

/* SPECIAL ASCII CHARACTERS */ 

DECLARE 

•00H' 

'03H' 



NULL 

CONTROL $C 

CONTROL$E 

BELL 

TAB 

LF 

VT 

FF 

CR 

CONTROLS? 

CONTROL$Q 

CONTROL$R 

COMTROL$S 

CONTROL$X 

CONTROL$Z 

ESC 

QUOTE 

LCA 

LCZ 

RUBOUT 



LITERALLY 
LITERALLY 

LITERALLY '05H ' 

LITERALLY •07H' 

LITERALLY '09H' 

LITERALLY ' 0AH ' 

LITERALLY »0BH' 

LITERALLY " 

LITERALLY " 

LITERALLY ' 

LITERALLY ' 

LITERALLY ' 

LITERALLY ' 

LITERALLY " 

LITERALLY ' 

LITERALLY * IBH ' 

LITERALLY '22H' 

LITERALLY •61H' 

LITERALLY '7AH' 

LITERALLY *7FHV 



' 0CH ' 
'0DH' 
'10H' 
M1H» 
M2H' 
M3H' 
'lOH' 
'lAH' 



9 
10 

11 
12 
1 3 

14 
15 
16 

18 
19 



ASC$2$B 
Procedu 
Dec 
Dec 
Dec 
Dec 
Dec 

/* Fi 
n=0 
Do 



e 

DP= 

/* Pr 

Do 



INARY: 

re (SRC$PTR,TRGT$PTR,SIZE) byte public; 

lare (SRC$PTR,TRGT$PTR) address; 

lare (SOURCE based SRC$PTR) (30) byte; 

lare RESULT based TRGT$PTR address; 

lare (N, SIZE, K, DP, DIGITS, VALID) byte; 

lare POWER (6) address data ( 

0,1,10,100,1000,10000 ); 
nd location of decimal point */ 

while SOURCE (n) <>'. ' AND SOURCE (n) OCR 
AND SOURCE (n)<>LF; 
n=n+l ; 
nd; 

n; 

ovide correct number of digits to right of decimal *'/ 

n=0 to SIZE; 

SOURCE (DP-fn) =SOURCE (DP+n-f 1 ) ; 

If SOURCE (DP-fn) >39H OR SOURCE (DP-fn) <30H 

then do k = n to SIZE; 
SOURCE (DP-!-k) = '0'; 

end; 
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e nd ; 
/* Mark end of string */ 

DIGITS=DP+SIZE; 
/* Test for all valid characters */ 

VALID=1; 

Do n=P to DIGITS; 

If SOURCE (n)>3S^H OR SOURCE (n) <3 0H 

then VALID=0; 
end ; 

If DIGITS>5 
then VALID=0; 
/* Convert data to binary and store */ 
n=0; 

If VALID=1 
then do; 

RESULT=0; 

Do while DIGITS > 0; 
RESULT=RESULT-f ( ( 

SOURCE (n) AND 0FH) * POWER (DIGITS )) ; 
n=n+l; 

DIGITS=DIGITS-1; 
end; 
end; 
/* Return to calling program */ 

Return VALID; 
end ASC$2$BINARY; 
end ASC$2$BINARY$M0DULE; 



MODULE INB'ORMATIOM: 

CODE AREA SIZE = 0178H 376D 
VARIABLE AREA SIZE = 0AH 10D 
MAXIMUM STACK SIZE = 0004H 4D 
80 LINES READ 
PROGRAM ERROR (S) 

END OF PL/M~80 COMPILATION 
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^TITLE( 'COMMON VARIABLE STORAGE') 
/*************************************** **•**-****** 

* This module contains those variables common to * 

* multiple tasks in the oven control application. * 
*****•*************•******************************/ 

VARIABLE$STORAGE: 

Do; 

Declare SETP0INT(4) address public; 

Declare TOLERANCE (^) address public; 

Declare TEMP(«^) address public; 

Declare STATUS (4) byte public; 

Declare BLOCKT: byte public; 

Declare BLOCKl byte public; 

Declare BL0CK2 byte public; 

Declare BL0CK3 byte public; 

end VARIABLE$STORAGE; 



MODULE INFORMATION: 

CODE AREA SIZE 
VARIABLE AREA SIZE 
MAXIMUM STACK SIZE 
16 LINES READ 
PROGRAM ERROR (S) 

END OF PL/M-80 COMPILATION 
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$TITLE('WORD TO ASCII CONVERSION') 
/**•***************•**•*•*********•***•***•***•***•** 

* This routine converts a fixed point word in mem- * 

* ory into a 4 digit plus 1 decimal ASCII display- * 

* able number. Zero blanking is included. * 
*******•*********************************•**********/ 

DEC$REP$MODULE: 
Do; 

DEC$REP: 

Procedure (SOURCE, TARGET) public ; 
Declare (SOURCE, TARGET) address; 
Declare ANSWR(5) byte; 

Declare (DISPLAY based TARGET) (5) byte; 
Declare NUMBER based SOURCE structure ( 

ELEMENT address ) ; 
Declare N byte; 
Declare CALC(5) address; 
/* Initialize */ 
Do n=0 to 4; 

ANSWR(n)='0*; 
end; 

CALC (0) =NUMBER. ELEMENT; 
/* Convert to ASCII */ 
Do n=l to 5; 

CALC(n)=CALC(n-l)/10; 

ANSWR(5-n)=(CALC(n-l) mod 10) + 30H; 
end; 
/* Perform zero blanking */ 
Do n=0 to 3; 

If ANSWR(n)<>'0' 
then n=4; 

else ANSWR(n)=' '; 
end; 
/* Format with decimal point */ 
Call move ( 4 , . ANSWR/FARGET) ; 
DISPLAY(4)=' . ' ; 
DISPLAY (5) =ANSWR (4 ) ; 
end DEC$REP; 
26 1 end DEC$REP$MODULE; 



MODULE INFORMATION: 

CODE AREA SIZE 
VARIABLE AREA SIZE = 
MAXIMUM STACK SIZE = 
40 LINES READ 
PROGRAM ERROR (S) 
END OF PL/M-80 COMPILATION 
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I. INTRODUCTION 

The utilization of computers to provide control or 
monitoring functions for industrial processes 
frequently results in complex computer systems. 
Distributing the control and processing intelli- 
gence throughout the control network reduces 
significantly the complexity of the system while 
increasing the reliability. The physical areas 
being controlled or monitored by each portion of 
the distributed system will generally consist of a 
relatively small number of I/O functions which 
are related by some control algorithm. 

The Intel iSBC 569 IntelHgent Digital Controller 
(IDC) and the iSBC 941 Industrial Digital 
Processor (IDP) are a part of the expanding line of 
Intel products which are oriented toward filling 
the requirements of these systems. This applica- 
tion note deals with the use of these devices to 
provide control of a closed loop system using a 
version of the FID control algorithm. 

It is assumed that the reader is familiar with the 
basic concepts required to generate software and 
has had some experience with using a computer. 
This application note will then guide the reader 
through a typical application, explaining in detail 
the decisions which must be made in order to 
effectively utilize a microcomputer to provide a 
control solution. 

The application which has been chosen is 
considered to be typical of the type which lends 
itself to control. The mechanical aspects of the 
application will be explained so that the user not 
familiar with the particular machinery will be able 
to understand the development. It will be seen 
that the techniques used will apply to any other 
specific application. 

The emphasis of the note will be on the use and 
implementation of the hardware and software 
features of the digital processor and controller. 
The actual FID control algorithm will not be 
developed in this application note. 

Reasons for Intelligent Boards 

The advent of microcomputers and the resulting 
trend toward utilizing these devices to control 
processes has resulted in many cases where the 
overall system performance has deteriorated 
because of the demands placed on the processor. 



In these applications, the computer has become 
overburdened with control algorithms, alarm 
detection, communications, and the many other 
tasks required of it. The processor can be inter- 
rupted by time dependent tasks to the point where 
other processing tasks can not be completed. 

Presently, Intel provides two I/O expansion 
boards which are capable of handling portions of 
the processing load which formally required 
processor time. These two devices are the iSBC 
544 Intelligent Communications Controller and 
the iSBC 569 IntelHgent Digital Controller. Tasks 
which involve communications or parallel digital 
I/O can now be offloaded without requiring 
valuable processor time. These boards can issue 
interrupts to the master or host processor if 
interaction with other processes or devices is 
required. This technique greatly increases system 
throughput by offloading the other bus master 
processors and by minimizing traffic on the 
Multibus system bus. 

In some cases, it will be found that the intelligent 
controller can function to control the process in a 
stand-alone environment, providing a more 
functional, low cost control system. 

The concept of offloading the processor of its 
input/output tasks can be developed on the iSBC 
569 controller through the use of slave processors 
which may be installed on the board to assist the 
host. The result is the ability to provide up to four 
processors on a single intelligent slave I/O board 
by using the concept of slave processors. 



The On-Board Slave Concept 

The utilization of the iSBC 569 controller is 
enhanced through the use of On Board Slave 
processors (OBS). These devices distribute the 
system intelligence and offload the processor on 
the intelligent controller. They can provide 
custom digital interfaces with the various devices 
which may be connected to the I/O ports of the 
controller. The OBS device allows a designer to 
fully specify his control /interface algorithm in the 
peripheral chip without relying on the master 
processor. Three types of OBS compatible devices 
are available from Intel. These are: 1) Industrial 
Processors, 2) Standard UPI devices, and 3) UPI 
8741 A for custom applications. By combining the 
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devices in various combinations, optimum solu- 
tions can be generated for different control 
applications. 

Before proceeding, we should cover the general 
characteristics of the OBS devices available for 
use in conjunction with the iSBC 569 controller. It 
will be seen that careful selection of the proper I/O 
controller chip can reduce significantly the design 
effort required to provide a control solution. 

II. BASIC UNIVERSAL PERIPHERAL 
INTERFACE DISCUSSION 

With the introduction of the Universal Peripheral 
Interface, Intel has expanded the intelligent 
peripheral concept by providing an intelligent 
controller that is fully user programmable. The 
8741 A i6 a complete single-chip microcomputer 
which connects directly to a master processor data 
bus. 

To fully understand the techniques used by the 
UPI 8741A devices, we must have a general 
knowledge of their characteristics. Only then will 
we feel comfortable in implementing a design 
which uses the components. 

Hardware Features 

Each Universal Peripheral Interface has IK bytes 
of program storage plus 64 bytes of RAM memory 
for data storage. It has a powerful, 8-bit CPU with 
a 2.5 /xsec cycle time and two interrupts. Over 90 
instructions are provided in its instruction 
set. Most instructions are single byte and single 
cycle and none are more than two bytes long. 
These instructions are optimized for bit manipula- 
tion and I/O operations. Special instructions are 
included to allow binary or BCD arithmetic 
operations, table lookup routines, loop counters, 
and N-way branch routines. 

The chip's 8-bit interval timer/ event counter can 
be used to generate complex timing sequences for 
control applications or it can count external events 
such as switch closures and position encoder 
pulses. Software timing loops can be simplified or 
eliminated by the interval timer. If enabled, an 
interrupt to the CPU can occur when the timer 
overflows. 

Two 8-bit bidirectional I/O ports are included 
which are TTL compatible. Each of the 16 port 



lines can individually function as either input or 
output under software control. 

The UPI microcomputer is fully supported with 
development tools. The combination of device 
features and Intel development support make the 
8741 A an ideal component for low-speed periph- 
eral control applications. 

Software Interface 

The OBS communicates with the processor on the 
host board by means of data transfers between its 
registers and the host board's data bus. A 
communication protocol has been defined which 
provides a set of rules by which the processors may 
interact with each other. Two types of software 
protocol are currently defined. These are the 
"simple" and the "extended" protocol. Before 
attempting to utilize the OBS devices in an 
application, the concepts used for the communica- 
tions must be fully understood. 

When used on one of Intel's single board compu- 
ters, the communication path is by means of the 
I/O ports on the host board. This means that two 
port addresses, an odd and an even location, are 
assigned to each OBS device. The even numbered 
port is used to transfer "data" between the 
processors. The odd numbered port is used to write 
commands into the OBS and to read its status. 
Each transfer between the host and the slave 
device consists of the movement of eight bits of 
information. 

Four of the eight bits available in the status 
message have been given predefined functions. 
The bit will be set (logical 1) when the correspond- 
ing condition exists within the OBS device and 
will be reset (logical 0) when the condition does not 
exist. The functions of the four bits are: 

Bit-0. Output Buffer Full (OBF). 

This bit indicates that the OBS has placed 
information into the transfer register and 
that the information is available to the host 
processor. It can be read by performing an 
input operation from the even numbered port 
assigned to the particular OBS. When the 
data has been read, the bit will automatically 
be reset to indicate that no data is available. 
As we will see, this is one of the key features 
enabling efficient utilization of the host/ 
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slave relationships on single board compu- 
ters. 

Bit-1. Input Buffer Full (IBF). 

This bit is used to indicate that data has been 
placed into the input transfer register by the 
host device and that it has not yet been read 
by the slave. Data is transferred into the 
input register by means of the host perform- 
ing an output to the even numbered port of the 
OBS. The bit will be reset when the device 
reads the data from the input transfer 
register into its accumulator. Data should 
only be output to the OBS when the IBF bit is 
reset! 

Bit-2. FO Flag. 

Unlike the IBF and the OBF bits which are 
controlled by hardware, the FO bit is control- 
led by the device software. The normal 
function of the flag is to provide a lockout to 
prevent the host from sending more data 
until the previous data has been processed or 
the operation is complete. 

Bit-3. Fl is the Command/Data Flag. 

It is automatically set when the host sends 
either a command (odd numbered port) or 
data (even numbered port). A logical 1 
indicates that a command has been sent and 
a logical indicates that data has been 
sent. This bit may also be cleared or toggled 
by the UPI software. 

These bits will provide normal communications 
between the master and slave processors. 

Figure 1 shows the sequence of operations which 
can be used by the host processor to establish 
communications with an OBS using the simple 
protocol. In Figure la, we see that all operations 
are initiated by the host. It will first verify that the 
IBF flag indicates that the input register is empty 
and available for receiving a command. The 
command is then sent to the odd numbered 
port. This command will inform the OBS that is to 
perform some task. The task may involve a 
requirement for more information to be sent to the 
controller and it may involve the controller 
returning some data to the host. Figure lb shows 
the operations required for receiving data from the 
OBS. 











SET 


^ 


CLEAR 


1 




WRITE 
DATA 










READ 
DATA 



DONE DONE 

HOST TO SLAVE SLAVE TO HOST 

Figure 1. Simple Protocol 

With these ideas in mind, we can move to a 
discussion of representative versions of the 
devices available for use on the IDC boards. We 
will then look at a typical application to see how 
they can actually be applied to solve a problem. 

Standard Universal Peripheral Controllers 

Intel presently manufactures three UPI control- 
lers for non-industrial applications. These are: 

1. 8278 Programmable Keyboard Interface 

2. 8294 Data Encryption Unit 

3. 8295 Dot Matrix Printer Controller 

These devices offer an "off the shelf solution to 
many applications which might be encountered. 

The Intel 8278 is a general purpose programmable 
keyboard and display interface device. The 
keyboard portion can provide a scanned interface 
to 128-key contact or capacitive-coupled key- 
boards. The keys are fully debounced with N-key 
rollover and programmable error generation on 
multiple new key closures. Keyboard entries are 
stored in an 8-character FIFO with overrun status 
indication when more than 8-characters have been 
entered. Key entries set an interrupt request 
output to the master CPU. The display portion of 
the 8278 provides a scanned display interface for 
LED, incandescent, and other popular display 
technologies. Both numeric displays and simple 
indicators may be used. The 8278 has a 16 x 4 
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display RAM which can be loaded or interrogated 
by the CPU. Both right entry calculator and left 
entry typewriter display formats are possible. 
Read and write of the display RAM can be done 
with auto-increment of the display RAM address. 

The Intel 8294 Data Encryption Unit is designed to 
encode and decode 64-bit blocks of data using the 
algorithm specified in the Federal Information 
Processing Data Encryption Standard. The DEU 
operates on 64-bit test words using a 56-bit user 
specified key to produce 64-bit cipher words. The 
operation is reversible; if the cipher word is 
operated upon, the original test word is produced. 
Because the 8294 is compatible with the NBS 
encryption standard, it can be used in a variety of 
electronic funds transfer applications as well as 
other electronic banking and data handling 
applications where data must be encrypted. 

Finally, the Intel 8295 Dot Matrix Printer 
Controller provides an interface to the LRC 7040 
Series dot matrix impact printers. It may also be 
used as an interface to other similar printers. The 
chip may be used in a serial or parallel communica- 
tion mode with the host processor. Furthermore, it 
provides internal buffering of up to 40 characters 
and contains a 7 x 7 matrix character generator 
which accommodates 64 ASCII characters. 



Industrial Digital Processor 

Intel produces the iSBC 941 Industrial Digital 
Processor (IDP) which is programmed to handle 
an assortment of typical industrial digital 
interfaces and transducers. The controller can 
function to provide any of the following: 

1. Scan up to 16 inputs for a change of state. 

2. Provide up to 8 gated one-shot outputs. 

3. Provide eight gated outputs with program- 
mable pulse widths and periods. 

4. Provide monitoring of up to 8 input lines for 
event sensing or as a programmable divider. 

5. Provide the period measurement of up to 
eight inputs. 

6. Provide a frequency to count conversion of 
one input. 

7. Provide for the control of a stepper motor 
having up to eight phases. 

8. Provide a simplex asynchronous serial 
input. 



9. Provide a simplex asynchronous serial 
output. 

In addition to providing one of the above 
functions, the IDP can also handle simple parallel 
I/O through the unused port inputs or outputs. 

III. FUNCTIONS OF THE INTELLIGENT 
DIGITAL CONTROLLER 

The iSBC 569 Intelligent Digital Controller (IDC) 
is a versatile digital I/O processor. The IDC is 
designed to operate in a system using any one of 
the following three modes: 

1. Intelligent Slave 

2. Stand-alone System 

3. Limited Bus Master 

Additional power is obtained by the utilization of 
three OBS's to generate up to 48 parallel input/ 
output data lines. 

In the intelligent slave mode, the controller's RAM 
is shared between the on-board 8085A and the 
Multibus users via a dual-port controller. Thus, a 
single bus master can control several intelligent 
slaves using the dual-port RAM as the major 
communications path. Switches are provided on 
the board to allow the user to reserve IK bytes of 
RAM for use by the 569's processor only. This 
reserved memory is not accessible via the Multibus 
system interface and does not occupy any bus 
address space. 

In the stand-alone mode, the entire system can 
consist of a single IDC, with cables, power supply 
and enclosure. An IDC can be installed at a 
remote site as a completely autonomous system. 

The IDC may also be operated as a limited bus 
master when it is the only bus master in the 
system. Expansion memory and I/O boards may 
be connected to the IDC via the Multibus system 
bus to increase the input/output capabilities. This 
mode could be used to configure one IDC as a bus 
master with additional IDC's as intelligent 
slaves. This mode is not available with any other 
bus masters such as iSBC single board computers, 
disk controllers, or DMA devices. 

Input/Output Functions 

The I/O interface between the iSBC 569 Intelhgent 
Digital Controller and the external devices to 
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Figure 2. IDC Functional Block Diagram 



which it is to be connected normally consists of 
various OBS devices. Each of these slaves has the 
ability to provide sixteen individual input and/or 
output lines. In addition, each provides two 
specialized input lines. The IDC is designed to 
accommodate up to three slave devices, so the 
normal I/O configuration of the board will consist 
of 48 digital data lines. If the specialized lines are 
considered, this number could be raised to 
54. Sockets are provided for the insertion of 
drivers or terminators for use on the 48 digital 
lines. The 6 special purpose lines can only be used 
as inputs and are provided with pull-up resistors to 
terminate the input signals. 



The driver /termination socket configuration 
limits the grouping of the I/O lines to be in groups 
of four. Any slave data line being used for an input 
must have its output latch placed into a logical 1 
state so as to allow the input line to be controlled 
by the external signal. 



IV. APPLICATION EXAMPLE 

An example of the iSBC 569 controller in an 
application will help to explain the techniques 
used to implement a control system and to 
interface between the various functional units. 
The application chosen will consist of a typical use 
but will be simple enough to allow the design 
operations to be easily followed. 

Suppose we choose to design a control system 
which will be produced as a subsystem to interface 
with and control a liquid applicator. As we go 
through the steps required to design and imple- 
ment such a control system, we will see how the 
various hardware and software tools which are 
available from Intel can be utilized to allow easy 
implementation of the task. 

Before proceeding, we will spend some time to 
insure there is a clear understanding about the 
definition of the liquid applicator. When this 
definition is complete, the design of the control 
subsystem can begin. 
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A liquid applicator consists of two functional 
parts: a device to control the flow of a solid 
material, and a device to control the flow of a liquid 
onto the material. We will actually be controlling 
two continuous process loops which are related by 
an input parameter which specifies the percentage 
of liquid to be applied to the dry material. 

Figure 3 shows the components making up a 
typical weighbelt feeder. The operation of the 
feeder is straightforward. The vertical gate is 
adjusted manually to provide a desired gap 
between the conveyor belt and the lower portion of 
the gate. This will result in a nearly level 
distribution of material on the belt when it is 
moving. The weighbelt is connected to a load cell 
to provide information back to the control system 
giving the amount of weight on the belt at any 
instant. If we know the speed of the conveyor, it is 
simple to compute the amount of material flowing 
through the feeder during any time period. This 



flow rate is known as the Mass Flow and is usually 
expressed as pounds per minute. The control of 
the feeder system can be provided by varying the 
belt speed until the desired flow rate has been 
obtained. 

Our control system will be designed to control the 
belt speed and to monitor the weighbelt weight and 
any other parameters which we determine will be 
necessary to control the flow of material. A typical 
control process will require an optimum flow rate 
be established for each material of a different 
density. With a known material flow through the 
feeder, we can go about the process of applying the 
liquid flow to the material in order to complete our 
application example. 

The second loop of the example will involve adding 
the liquid to the material coming from the feeder 
mechanism described above. Normally, the 
percentage of material to be applied is fixed by the 
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Figure 3. A Weighbelt Feeder 
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formula or mix design of the product which we are 
manufacturing. However, since the flow rate 
through the weighbelt feeder can and does vary 
(our first control loop will not always be able to 
exactly control the flow due to many conditions 
beyond our control), the liquid setpoint will 
constantly be changing as a function of the actual 
mass flow and the liquid percentage. 

Figure 4 shows the liquid application piping 
diagram for the liquid portion of the control 
system. The items with which we will be directly 
concerned are the liquid flow meter and the control 
valve. The other components, while requiring 
consideration in an actual implementation, will be 
ignored in this aplication note for the sake of 
clarity. Let us consider the details of each control 
loop in more depth before we attempt to design the 
control system. 

Mechanical Specifications 

In subsequent portions involving development of 
the control system, we will be constantly referring 
to data regarding the mechanical specifications of 
the liquid applicator system. Therefore, we will 



establish a set of theoretical technical specifica- 
tions for our system. Later, we will see how close 
the control system can come to providing a control 
which meets or exceeds these parameters. These 
specifications will be broken down into two sets of 
data, one for physical parameters over which we 
have no control, and a second for the desired 
control characteristics. 

The physical data provides information on the 
mechanical design and will be used for guidelines 
in selecting interface equipment and in preparing 
software algorithms. The physical data is: 

Operating Belt Speed — 

1.1 to 180 feet per minute. Adjusted by a 
variable speed motor directly coupled to the 
belt pulley mechanism. 

Feed Output Rates — 

Adjustable over a 10:1 range with a maxi- 
mum output of 960 pounds per minute. 

Feeder Belt Characteristics — 

The belt will be 9 inches wide by 2 feet in 
length when installed. The belt pulley rollers 
will have a radius of 4.5 inches. 
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Figure 4. Liquid Flow Diagram 
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Feeder Weight Sensor — 

The weighbelt feeder will incorporate a strain 
gauge load cell to measure the weight on the 
belt. Its linearity shall provide 0.1% of full 
scale range. 

Liquid Flow Rates — 

The liquid flow rates shall vary between 10.0 
and 120.0 pounds per minute. 

The desired operating characteristics of our 
control system will provide the following general 
responses: 

Feeder Accuracy — 

1% of full scale over a 10:1 range. The feeder 
will maintain the set feed rate within 1% of 
full scale over any one minute period. The 
minimum sample must be at least one pound. 

Liquid Accuracy — 

1% of full scale over the operating range. 
Must be able to track mass flow variations 
within the above limits. 

These specifications will provide guidelines for 
the decisions which we will later make in 
providing a micro-computer control solution to the 
weighbelt feeder application. 

Interface Requirements 

A logical place to begin the consideration of the 
control system design is to examine the interface 
requirements and define the characteristics of the 
interfaces which will be required to implement the 
control. We will consider each element of the 
physical system separately. 

Weighbelt Weight 

The weighbelt weight will be sensed using a lever 
system connected to a load cell integral to the 
mechanical unit. The output of a strain gauge 
load cell is a low level (approximately 20 millivolts 
at full scale) analog output. Obviously, this signal 
must be somehow converted into a digital level 
before we can use its information to compute the 
actual mass flow across our weighbelt feeder. Our 
design process must define the characteristics of 
the digital signal so that the appropriate analog to 
digital converter system can be chosen. The 
design path can take any of several equally valid 
approaches, any of which will provide a func- 
tional control system. For the purposes of this 



application note, we will assume that the design 
path will utilize the Intel iSBC 569 Intelligent 
Digital Processor. 

This assumption requires us to utilize only signals 
which can be generated or interpreted using the 
computer board and its associated OBS's. We will 
not be capable of handling an analog signal. 
Since some type of signal conditioning would be 
required of the low level analog voltage anyway, 
this does not impose any serious restrictions on 
our design. Indeed, it will cause us to consider a 
technique which provides excellent noise rejection 
characteristics. We will assume that a voltage to 
frequency converter (V/F) will be installed near 
the load cell and the frequency will then be 
transmited over a pair of wires to our digital 
interface. Commercially available converters 
provide a frequency output which varies between 
and 10 kilohertz. With this in mind, we can 
continue with the development of the interfaces 
required in the application. 

The load cell transducer will incorporate a local 
unit which generates a pulse train whose fre- 
quency is proportional to the weight upon the load 
cell. This mechanical arrangement is typical of 
many gravimetric feeder systems in use today. 

For purposes of this application, it will be assumed 
that the system will be calibrated such that a 
weight of 10.00 pounds on the weighbelt will 
produce a pulse train frequency of 10 khz. No 
weight on the belt will generate a frequency of less 
than 30 hertz. The accuracy of the pulse output 
will be guaranteed to be proportional to the weight 
within 0.05%. Again, this is typical of devices 
available and in general use in similar applica- 
tions. 

The characteristics we have described above fall 
within the performance range of the iSBC 941 
processor when operated in its frequency to count 
mode. If we assume a sample rate of 200 msec 
(this value should provide an adequate control 
characteristic since it is unlikely that the 
mechanical equipment can respond rapidly 
enough to warrant a faster control and sample 
time), the frequency count read by the iSBC 941 
counter will range between 6 and 2000. System 
accuracy of reading the belt weight will thus 
exceed 0.1% of the full scale weight reading. 
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We will discuss the electrical and programming 
interfaces in subsequent sections of the applica- 
tion note. 

Weighbelt Motor Control 

The flow on the weighbelt will be controlled by 
changing the speed of the belt movement. Since 
the weighbelt is mechanically designed to main- 
tain a constant bed level, the amount of material 
flowing will thus be adjusted. 

The belt speed has traditionally been adjusted 
using either SCR controllers or by using variable 
transmissions between the motor and the con- 
veyor belt. The increased utilization and develop- 
ment of stepper motors is leading toward greater 
use of direct stepper motor drives. This is the mode 
which will be utilized for this application. 

The manufacturer's specifications for the weigh- 
belt indicate that the following requirements exist 
for driving the device: 

REQUIRED TORQUE - 149 LB-IN-IN 
REQUIRED MAX SPEED - 2.54 REV/SEC. 

Referring to typical manufacturer specification 
sheets for stepper motors, we find the torque vs. 
speed characteristics shown in Figure 5. Our 
application requires 2.54 revolutions/sec which 
translates to 508 steps per second when the 
stepper is used in a 1.8 degree per step mode. We 
can see that the requirements fall well within the 
capabilities of the particular motor. 
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At this point, we have four routes which may be 
pursued to actually interface with the motor. These 
are: 

1. Utilize the iSBC 941 stepper mode to drive 
the stepper motor directly. 

2. Utilize the iSBC 941 frequency generation 
mode to drive a standard stepper translator. 

3. Utilize parallel outputs to provide a digital 
output to a stepper translater. 

4. Utilize a 4-20 ma. current signal to a stepper 
translator. 

Three of the above modes use a translator to drive 
the motor. If possible, we should strive to 
eliminate the cost of this intermediate device. 

Again, we will refer to the published motor 
specification sheets. For our typical motor, ^^ 
data is shown in Figure 6. The requirement for 
providing in excess of six amperes per winding 
exceeds the capabilities of the output drivers 
which can be installed on the iCS 930 termination 
board. We will be forced to either design a custom 
high power driver board or to use a translator 
module. To keep the application as simple as 
possible, we will choose the latter. 
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Figure 6. Stepper Electrical Ratings 



Figure 5. Stepper Motor Torque/Speed 



We have three choices left when the decision has 
been made to use a translator module. The use of a 
current output mode will necessitate the use of an 
external analog board. This is undesirable, both 
from the standpoint of interboard communication 
requirements, and from a cost effective basis. 

The use of a parallel output would commit many of 
our output data ports and would require the 
installation of UPI modules or iSBC 941 modules 
to get the parallel output drivers. In addition, 
parallel digital input is not a common option of 
commercially available translators. 
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This leaves us with the use of a variable frequency 
output to provide stepping information to the 
translator module. This is a normal operational 
mode of the iSBC 941 processor and the required 
508 hertz is within the normal output range of the 
device. 

A definite advantage of our decision to use a 
stepper motor drive for the weighbelt is that we do 
not have to maintain accurate feedback and 
control algorithms to maintain the conveyor 
speed. Only a simple check need be made to verify 
that the conveyor has not stalled. The stepper 
motor will inherently maintain a speed propor- 
tional to the frequency rate. 

The actual electrical and programming interfaces 
will be discussed in subsequent sections of this 
application note. 

Weighbelt Speed Measurement 

We have mentioned that a control system using a 
stepper motor for speed control can operate 
effectively in an open loop configuration. How- 
ever, since a faulty component could result in 
failure of the motor to run, we must verify that the 
belt is indeed moving. This is easily accomplished 
by adding a magnetic sensor to the weighbelt 
rollers and counting the pulses generated as the 
device operates. 

Typical magnetic sensors and ring magnets for 
installation on the weighbelt will provide us with 
ten pulses per revolution of a belt pulley. Since the 
pulley is operating at a maximum speed of 2.54 
revolutions per second, we will receive between 
and 25.4 counts per second. Using our sample 
period of 200 milliseconds, this means that we will 
count between and 5 counts during each time 
interval. Our decision to use a stepper control loop 
rather than a conventional closed loop seems 
justified as we would obtain rather poor control 
with feedback having this poor of resolution. 

We must make a decision to determine how the 
speed will be sensed by the control board. An 
obvious choice would be the use of an iSBC 941 
processor operating in the period measurement 
mode. This would require using our third socket 
on the iSBC 569 host board and would leave us 
without the ability to use an additional device to 
support the liquid control loop. We should seek an 
alternative solution. 



The iSBC 569 controller board provides an 8253 
programmable interval timer. A first approach 
might be to attempt to configure one of these 
counters to provide an event counting mode and 
read the belt speed from the counter. However, 
this is not possible since we would be required to 
zero the counter after each reading and the 
counter does not load the preset count until a clock 
pulse is present. We would have no ability to 
distinguish between no belt motion and the belt 
motion which is the same as the previous reading! 

An alternative approach is to create a software 
counter by routing the belt movement pulse to one 
of our interrupts and creating a program which 
will increment a counter. Each time a count is 
sensed, the software will increment a memory 
location by an increment which corresponds to the 
speed represented by one count. 

Again, we will delay the discussion of the 
electrical and programming interfaces until 
subsequent sections of this application note. 

Liquid Flow Control 

The design of a control system to provide control 
of flow through a liquid valve is an integral part of 
the liquid pipe and plumbing design. To optimize 
the system operation and provide a system at the 
minimum cost, the integration of control and 
mechanical design must be made. 

Several possibilities exist when making a decision 
as to which control valve to use in adjusting the 
liquid flow rate. The actual selection of the 
physical valve mechanism should be based upon 
the characteristics of the liquid flow. This 
decision is outside of the scope of this application 
note and will not be pursued. However, the valve 
actuator is a device which becomes an integral 
part of the control system and its selection is a 
function of the control system design. 

Figure 7 shows the common control valve types 
which are used to vary the flow rate of liquids. 
The automatic control system we are designing 
precludes the use of a manual valve, so we must 
make our selection between the air actuated and 
the motorized control valve. 

Classical control design has utilized air actuated 
valves almost exclusively. This type of actuator 
incorporates an intermediate transducer to 
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Figure 7. Control Valve Family 



convert the signal generated by the control system 
into a variable air pressure. This air is used to 
drive a pneumatic control actuator. Two types of 
electrical to pneumatic transducers are in com- 
mon use. The most prevalent converts a 4 to 20 
milliampere control signal into a proportional air 
signal. The second type will accept a to 10 khz 
pulse train and convert this to an air output. 

Both of the above systems provide excellent 
electrical noise immunity and give reliable 
operation in industrial environments. They do, 
however, have disadvantages. A supply of air 
must be present at the control devices and this air 
must be maintained such that it is free from water 
and oil. In many cases, this presents costly 
installation and maintenance considerations. 
The use of computerized control systems has led to 
a recent concept of eliminating the intermediate 
conversion and using instead a digitally control- 
led actuator. 
A stepper motor can be connected to the actuator 



of the control valve to provide a simple and 
economical control path. The control outputs 
from the PID control loop can be sent to the iSBC 
941 processor's command queue and the controller 
will handle the motor movements. 

The electrical and programming interfaces of this 
interface will be fully discussed in subsequent 
sections. 

Liquid Flow Measurement 

The use of a liquid control valve to vary the liquid 
flow cannot in itself provide an accurate control 
loop. Because the flow rate through a fixed valve 
will vary with material densities, temperatures, 
and pressures, we must provide some type of 
feedback into our control algorithm. Thus, a 
flowmeter must be inserted into the liquid flow 
and its output returned to the system. 

The control system designer can choose from 
several types of flow meters depending upon his 
requirements. Figure 8 shows many of the more 
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Figure 8. Flow Meter Classifications 
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standard classifications of flow meters. Our 
selection of the meter must take into account the 
type of electrical interface available from the 
meters. In our attempt to maintain a digital 
system which does not require additional support 
boards, we will reject the use of a magnetic 
flowmeter because this type of meter provides an 
analog type of output which would require the 
addition of another board into our control 
system. The wobble meter provides a digital pulse 
type output but its accuracy tends to discourage its 
use in a refined control loop. We will utilize the 
turbine meter for our liquid flow application. 

The output of a turbine meter is a low voltage, low 
current AC signal whose frequency is proportion- 
al to the liquid flow rate. The manufacturers of 
the meters provide pre-amplifiers which convert 
the signal into 10 volt peak to peak square waves 
which are equivalent in frequenacy to the AC 
pulses. The operating frequency ranges typically 
from 100 to 1200 pulses per second. 

It is desirable to measure the flow rate using a 
single iSBC 569 controller. If we consider that a 
200 millisecond control interval will be used, the 
flow will result in a reading of between 20 and 240 
pulses per sample period. These readings could be 
performed using an iSBC 941 processor, but we do 
not have the socket available for a fourth module, 
so we must consider utilizing another interrupt 
driven software counter as was done with the belt 
speed. 

All control and monitoring equipment for our 
liquid control application has now been defined in 
such a manner as to be compatible with the 
utilization of a single iSBC 569 controller 
board. The actual interfaces to perform the 
interconnections and to provide control instruc- 
tions can soon be considered. 

Operator Interface 

Finally, we must define the data communications 
which must take place between the controller, 
other system tasks, and the operator. Let us first 
consider the system control variables and the data 
which, if generated by the control process, might 
be useful to the remainder of the control system. 

The first variable which comes to mind is the 
liquid flow setpoint. If we consider the entire 



control system, this parameter will be found to be 
actually expressed as a percentage of the total 
output material. For example, if we assume the 
recipe required the final product to consist of 5% 
liquid by weight, we would require that our control 
system add the correct amount of liquid to perform 
this task. 

To allow maximum flexibility of the control 
system, we should allow selection of various 
density materials onto the weighbelt. A host 
processor with computational capabilities can 
calculate the optimum gravimetric feeder flow rate 
for the materials being combined. 

The control system can provide an integration 
function to allow totalization of the amount of 
material which has been transferred through the 
system. A capability of outputting the amount of 
material which has passed over the weighbelt and 
the amount of liquid added will be included. 

The implications of the parameter storage and 
generation will be dealt with later when the 
host/slave relationships of the iSBC 569 controller 
are discussed. 

Interface Summary 

We have defined the required interfaces which will 
be needed to perform our control task. These can 
be grouped into external and internal interfaces. 
The external interfaces are those which connect to 
physical pieces of external equipment. 

These are summarized in Figure 9. The internal 
interface relates to the data which is to be passed 
between the iSBC 569 Intelligent Slave board and 
other boards which may be present on the 
MULTIBUS system bus. These data areas are 
shown in Figure 10. 

V. HARDWARE CONFIGURATION 

We have now defined the various components 
which we will utilize on the controller board to 
support the physical control and monitor hard- 
ware. Our next task is to provide an interface 
between the controllers and the equipment which 
we are to control. In so doing, we will define the 
hardware I/O assignments for the iSBC 941 
processors and for the counters which we will be 
utilizing. The following paragraphs will deal 
with the optimization of this configuration. 
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* * * * DEVICE * * * * * 
WEIGHBELT MOTOR 
WEIGHBELT WEIGHT 
WEIGHBELT SPEED 
LIQUID VALVE 
LIQUID FLOW 



* * * * SIGNAL TYPE ' 
10 VDC PULSE 
10 VDC PULSE 
110 VAC PULSE 
5 VDC MULTIPHASE 
10 VDC PULSE 



**** BOARD ELEMENT* 

iSBC 941 

iSBC 941 

8259A INTERRUPT 

iSBC 941 

8259A INTERRUPT 



Figure 9. Control/Monitor Signals 



*** INPUTS ******** 
GRAVIMETRIC FLOW 
LIQUID PERCENTAGE 



******** OUTPUTS * * * * 
ACCUMULATED SOLIDS 
ACCUMULATED LIQUID 



Figure 10. Communication Signals 



Controller Interface 

Good design practice dictates that we should 
provide optical isolation between the controller 
and the external equipment when designing for an 
industrial environment. The optical isolation is 
included if we utilize the Intel iCS series of signal 
conditioning/termination boards. We find that 
we have two types of digital termination panels 
available, one for low current, low voltage 
applications and second for higher current and 
voltage uses. If we base our choice on the data 
provided by Figure 8, we will lean toward using the 
iCS 930 panel for our interface. This board can 
handle a mixture of signal levels and will support 
up to sixteen individual lines, providing almost 
double our needs. 

Even a cursory glance at the iSBC 569 controller 
will provide the knowledge that three edge 
connectors are utilized to bring the OBS signals 
from the board. This would indicate that the 
simplest (and most costly) solution is to use three 
termination panels. Obviously, we should investi- 
gate further before making such a decision. Three 
possibilities are readily apparent. First, we might 



perform some type of re-routing of data lines on 
the board so as to use only one connector. Second, 
we can use more than one connector on the ribbon 
cable and perform a parallel connection of the 
various lines and choose them so that no 
duplication of lines results. Finally, we can use 
some scheme of connecting three cables to the 
board and use the optional Port C connectors on 
the termination panel. 

The schematic drawings of the IDC indicate that 
only six of the OBS I/O lines of each processor 
socket are broken by wire wrap jumper posts. All 
of the lines so configured are on the Port 2 data 
lines. Unless we decide to cut etch and add 
soldered wires, we will not be able to configure our 
board with this technique. Some further investi- 
gation is in order before we can make a decision. 
The use of a parallel output technique using 
multiple connectors on a single cable seems to 
present a feasible approach if we can wolrk out an 
assignment of I/O which will not cause conflicts. 
We will begin by building a trial port assignment 
table in which we will assign the required 
functions to input/output ports. We will group the 
inputs and outputs into groups of four to handle 
the terminator/ driver arrangement which is built 
into the board. This table is shown in Figure 
11. We obviously have a small problem. We have 
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Figure 11. UPI'" Socket to Terminator Initial Assignments 
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not yet shown the signals from the conveyor speed 
and the Hquid flow into the on-board interrupt 
counters. The schematics show that these signals 
are brought onto the board on the edge connectors 
but the locations correspond to Port C lines which 
do not exist on the iCS 930! We have available 
input lines on the Port 1 connectors but there is no 
provision to break the signal on the board to route 
it to the counter interrupts. 

If we move on to the third alternative, we find that 
the interconnection paths caused by tieing 
various lines together cause even greater prob- 
lems. Either some fact must have been over- 
looked, or we must consider the use of more than 



one terminator board. 

Figure 11 indicates that three lines are available 
on the Port 2 data lines which go to jumper posts 
and which could be used if they were not part of an 
output driver of Port 20. If some technique can be 
found to use these "output" lines as inputs, our 
problem will be solved. The use of an open 
collector driver can provide us with the ability to 
use the line as an input so long as the drivers are 
turned off! This should be no problem as we can 
force the outputs to this state either through the 
appropriate jumpering of inputs or by outputting 
data to the OBS 1 ports corresponding to these 
bits. The resulting electrical configuration can be 
seen in Figure 12. 
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Figure 12. Port Assignments 20-23 
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Let us examine the implications of performing 
this interconnection. The physical layout of the 
board and the use of the terminator /driver sockets 
causes the I/O lines to be grouped into sets of four 
data lines.We must choose which of the three iSBC 
941 modules will be responsible for supporting 
each of the lines. In Figure 12, we can see that the 
belt motor is driven by OBS Socket 1, Bit 20. This 
requirement has placed output drivers onto data 
Bits 21, 22 and 23. Our requirement is to provide 
two signals which can be routed to the counter 
inputs so we must place a terminator into either 
socket AlO or Al6. We have arbitrarily chosen to 
use socket AlO. The use of the terminators in 
parallel with the drivers will not create a problem 
so long as those lines which are used as inputs 



have the driver in the high impedence state. This 
is done by requiring that the output Bits 21 and 22 
of the device placed into socket 1 are driven 
low. Finally, we see that the remaining Bit 23 may 
be used as a general purpose output line if it 
becomes required. 

The wiring configurations for the remaining 
connector groupings are shown in Figures 13, 14 
and 15. In Figure 13, we see the assignments 
which can be used for Bits 10, 11, 12 and 13. We 
have earlier defined that an iSBC 941 processor 
would be used in a high speed frequency counting 
mode to determine the weighbelt weight. This 
device will be placed into socket 2. The use of this 
mode precludes the use of any general purpose 
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Figure 13. Port Assignments 10-13 



3-77 



input/output operations of the processor if we 
desire to maintain maximum accuracy of the 
frequency measurement. We will arbitrarily 
choose to use Bit 10 as the location of the 
frequency count input. This will necessitate 
installing a terminator into the socket correspond- 
ing to the processor input. If required, we can 
install open collector drivers into socket A 14 and 
use the remaining three bits for general purpose 
outputs. If this is done, care must be taken to 
assure that Bit 10 of the device which is placed into 
socket 3 is placed into a low state as was done in 
the preceding example. 

The interconnection scheme for Ports 14 through 
17 can be seen in Figure 14. Note that no ports of 
this group are dedicated to our defined control 



functions. These four bits may be used as inputs 
or outputs as required by the application. For 
example, we have ignored the fact that actual 
control loops incorporate solenoids for flow 
control routing. The unused bits can be used to 
perform these tasks. 

Figure 15 shows the interconnections for the 
remaining group of bits. There are several 
features shown on this drawing which should be 
discussed in some detail. Let us first consider the 
remaining function which we must implement. 
This is the control for the liquid valve stepper 
motor. An iSBC 941 IDP operating in the stepper 
mode will provide the necessary control functions 
to drive the motor. Since all four of this group's 
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Figure 14. Port Assignments 14-17 
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data lines are committed to drive the four phases of 
the stepper motor, there are no other functions 
available. 

An important feature of the iSBC 941 processor is 
illustrated in Figure 12. This is the ability to 
enable the processor to generate an interrupt at 
some point in its operation. We have earlier 
indicated that we will use the processor in socket 2 
(the frequency counter) to provide us with a 200 
msec time reference. When the iSBC 941 proces- 
sor is enabled with an ENFLAG command and is 
operating in the frequency count mode, it will 
generate an interrupt on its output line, Port 
25. Figure 15 shows how this interrupt can be 
connected to the host board's internal interrupt 
input structures. 



The hardware configuration has been defined 
through Figure 14. The actual implementation 
can be handled through the use of the various 
wire-wrap jumpers on the IDC. Drivers and 
terminators can be installed as indicated in the 
preceding discussion. 

VI. SOFTWARE CONFIGURATION 

As with most computer controlled systems, the 
actual implementation of the task is handled with 
software. In older designs and in many mini- 
computer systems, this task has become formid- 
able and has resulted in cost over-runs and 
schedule delays. Intel provides many tools for use 
by the designer to prevent this type of problem and 
to assist him in easily creating a workable and well 
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documented software configuration. Let us look at 
some of these tools in more detail and consider how 
their use will help us to write our programs easily 
and quickly. 

High Level Programming Languages 

A valuable tool, which Intel provides the designer 
of small control systems, is the ability to program 
even the smallest systems using a high level 
programming language, PL/M-80. This language 
offers relatively efficient and structured, program- 
ming capabilities. It has been determined that 
PL/M-80 users can expect to use between 1.1 to 
slightly more than 2 times as much program 
memory as would be used for the same task written 
in assembly language. At the same time, the 
programmer's time to code a task will be consider- 
ably less than if he were to use assembly language. 

The PL/M-80 Programming Manual indicates 
that the language is highly structured and lends 
itself very well to handle logical type operations. 
Its weakness in handling complex mathematical 
computations is compensated by the ability to 
combine the user application software with 
packaged Intel support software. 



4. The decimal arithmetic routines which 
perform integer and fixed point computa- 
tions on numbers which are stored as 
strings of ASCII characters. 

5. A string handling section which contains 
routines to transform strings and to extract 
and insert substrings. A routine for scan- 
ning of general input and one for formatting 
of general output are included. 

6. Routines for number conversion, for numer- 
ic I/O transformation of data from one 
format to another, input scanning of 
numeric strings, and formatting of numeric 
strings for output are also available. 

7. The floating point transcendental function 
section provides trigonometric, exponential, 
and other transcendental functions. 

8. The statistics routines compute the mean, 
variance, and standard deviation of one 
group of statistical data, and the covariance 
and correlation factor of two groups of data. 

9. Finally, the PID procedures provide the user 
with a version of the classical Proportional, 
Integral, Derivative control algorithm. 

Clearly, the use of the FSP support programs 
enhance the logical PL/M-80 program operations. 



Fundamental Support Packages 

The Intel 8080/8085 Fundamental Support Pack- 
age (FSP) provides a package of application 
subroutines and functions which can be called 
from programs written in either assembly lan- 
guage, PL/M-80, or in FORTRAN-80. It uses a 
standard set of data structures and a unified status 
and error reporting scheme. Nine major groups of 
operations are fully supported by this package. 
These are: 

1 . A primitive fast string handling and integer 
arithmetic capability without error report- 
ing. 

2. A binary integer arithmetic package which 
performs operations on both signed and 
unsigned integers of various lengths in 
binary representation. 

3. The floating-point arithmetic package 
which provides operations on floating point 
numbers in four formats: single precision, 
single-precision extended, double precision, 
and double-precision extended. 



Host/Slave Relationship 

Before we proceed with our development, we 
should take some time to examine the relationship 
between our iSBC 569 IDC and other controllers 
which may be installed in the system. The 
utilization of intelligent slave boards provides the 
capability to develop control concepts to an 
extremely high level if certain guidelines are 
followed. We will therefore assume that the 
control solution which we are developing will be 
but a part of an over all control concept which 
utilizes multiple controllers sharing common 
resources. 

This concept allows us to develop control algo- 
rithms for each sub-process within our overall 
control system. This development can provide 
independent design and implementation of each 
process. A host processor can be used to provide 
any required inter-process communication tasks 
and to provide the operator interface. We have 
previously indicated that the operator interface 
will provide some means to adjust the weighbelt 
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feeder setpoints and the liquid ratio. It should also 
allow the operator to display the current status of 
the process. Since these operator interface func- 
tions are but a part of the overall control functions, 
the interface should be programmed such that 
maximum flexibility can be gained through its 
use. Fortunately, such an interface is available 
using Intel's RMX/80 BASIC-80. 



RMX/80 BASIC-80 Interpreter 

The RMX/80 BASIC-80 Interpreter is a high level 
language interpreter with extended disk capabili- 
ties. It operates on iSBC 80 Single Board Compu- 
ters and allows the interpretation of BASIC-80 
source code into an internally executable form. 
Many other features are available and many 
configurations are possible depending upon the 
exact system requirements (refer to the BASIC-80 
Reference Manual, 9800758). 

Maximum utilization of the operator interface 
with a minimum of development time can be 
achieved with the preconfigured version of the 
software/hardware package. This will provide us 
with complete disk I/O capabilities and the ability 
to easily program and maintain any programs 
which may become necessary to implement the 
interface. The actual implementation of the 
interface will be done later, after we have defined 
the control task. 

Softw^are Tasks 

The task of preparing the software can be broken 
down into three major groupings or tasks. These 
are defined to be: 

Prepare the Software Drivers. 

This involves defining the relationships 
between the control algorithm parameters 
and the input/output hardware devices and 
creating software to implement these defini- 
tions. 

Prepare the Control Algorithm. 

This will involve developing a control 
algorithm which defines the relationships 
between the various system parameters. This 



algorithm will draw heavily upon the re- 
sources of the FSP programs and the soft- 
ware drivers which relate the parameters to 
the physical hardware. 

Finally, the operator interface must be defined 
which will relate the parameters used in the 
control scheme to other controllers and to the 
operator. This will allow the control task to 
interact in such a manner as to provide a 
meaningful element of the overall control 
concept. 

VII, SOFTWARE DRIVERS 

Before developing the actual control algorithm, we 
must create the drivers which communicate with 
the three iSBC 941 processors in their assigned 
operating modes. We will define two driver 
sections for each processor, one to handle the 
initialization, and a second to provide the ongoing 
communications as required by the control 
algorithm program. 

Motor Speed Control Processor 

The first processor which we will discuss is to be 
located in slave socket number and will be used to 
produce a variable frequency output. Let us 
consider in some detail how this can be accom- 
plished using an iSBC 941 Processor. First, 
consider the task of initializing the device to the 
primary function operating mode, FREQ. 

Referring to the iSBC 941 Industrial Digital 
Processor User's Guide, we find that the initializa- 
tion requires the sequence of commands and data 
shown in Figure 16. We will identify the meaning 
of each of these terms and create a software 
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Figure 16. FREQ Initialization 
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program which will handle the required initializa- 
tion of the processor. The purpose and use of the 
various commands to the processor are well 
defined in the user's guide and will not be repeated 
here. 

The first byte of data, which must be sent 
following the initialization command, is the data 
byte signifying that the operational mode is to be 
the frequency output. This is defined in the 
manual as being equal to the data byte "0B5H" or 
"035H" as expressed in the hexadecimal number- 
ing system. The choice of values to be sent is 
dependent upon our desire to utilize the internal or 
external time reference period for the operations. 
If we utilize the internal time reference, our 
minimum increment or resolution of operations 
will be 86.72 microseconds. 

To determine if this speed is adequate for our 
frequency generator, we must consider the impact 
that this resolution has on the output. A 550 hertz 
signal has a period of 1.82 milliseconds. If we 
increase this period by the 86.72 microsecond time 
reference, we find that the next increment in the 
frequency generators output will be approximately 
372 hertz. This resolution is certainly not ade- 
quate to meet the motor control requirements! We 
should consider using the external clock to provide 
the time reference. One of the 8253 Interval 
Timers on the iSBC 569 board can be used to 
generate a reference time. If we arbitrarily choose 
to use a 10 microsecond reference to the IDP, we 
find that the worst case resolution for the 550 hertz 
signal becomes about 4 hertz. This is certainly 
within our requirements of motor control. The 
primary function signal should then be sent as a 
''0B5H". 

The second byte is used to establish a scale factor 
for the processor. This scale factor is used to 
generate the basic time increment which can be 
used to establish the frequency output; that is, the 
minimum time increment which can be used to 
establish a period or pulse width will be the scale 
factor times the reference time period. 

In our case, because of the wide frequency output 
range, we cannot specify the scale factor at 
initialization (later data will show the need for 



multiple scale factor ranges). We will then only 
need to send some arbitrary value at initialization 
to allow the processor to complete its initialization 
sequence. 

The Output Enable data byte is used to select 
which of the Port 2 output bits are to be used to 
generate the output signals. The hardware 
configuration established earlier placed the output 
onto Bit of the port, so this data byte shall be 
specified as a byte having only Bit set to a logical 
one or equal to OIH. 

The Initial Output parameter specifies whether 
each bit selected as an output by the output enable 
byte is to be initially set to a logical one or zero 
when the processor is first enabled. For this 
application, it really does not matter, but we will 
arbitrarily pick the state to be equal to zero. The 
byte will be defined as being set to OOH. 

The Delay parameter is used to define the 
waveform which will be generated and specifies 
the number of time increments which must elapse 
before the waveform will change states. Rather 
than to constantly vary the delay to maintain a 
square wave output, we can choose an arbitrary 
value of one time increment before changing 
state. The output will have a varying duty cycle as 
the frequency changes. This should cause no 
problems for the translator driving the weighbelt 
motor. The byte will be defined as being set to a 
value of OIH. 

Finally, the Period of the waveform must be 
chosen. Again, this parameter will be changed 
according to the desired frequency, so only an 
arbitrary value need be sent. Indeed, since this is 
the last parameter, the value could be omitted 
entirely by sending the PAUSE command in its 
place. 

The initial data definition can be defined using 
PL/M-80 language conventions as a block of six 
bytes as shown in Figure 17. 

The actual communications between the host 
processor on the iSBC 569 board and the IDP 
utilizes the protocol explained in previous sections 
of this note. The status register of the IDP will be 
tested for the bit signifying that the input buffer 
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/• DECLARATION OF iSBC 941 #0 INITIALIZATION DATA •/ 
DECLARE FREQ LITERALLY '0B5H'; 

DECLARE SF LITERALLY 'OOOH'; 

DECLARE OUTPUT$ENABLE0 LITERALLY '001 H'; 
DECLARE INITIAL$STATE LITERALLY 'OOOH'; 
DECLARE DELAY LITERALLY '001H'; 

DECLARE PERIOD LITERALLY 'OOOH'; 



34 



/• DECLARATION OF ISBC 941 PRIMARY DATA •/ 
DECLARE INIT$0$TABLE(6) BYTE DATA ( 
FREQ, 
SF, 

OUTPUT$ENABLE0, 
INITIAL$STATE, 
DELAY, 
PERIOD ); 



Figure 17. Initial FREQ Data Field 



full is not set. This will indicate that the device is 
ready to accept either a command or a data 
byte. The command to request a primary function 
will be sent. At this point, the processor will be 
expecting a series of data bytes as specified by the 



function being selected. A "Do Loop" can be used 
to effectively transmit this data to the device. The 
program to perform this function is illustrated in 
Figure 18. 
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/• REQUEST PRIMARY FUNCTION •/ 

DO WHILE ( (INPUT (UPI$0$STATUS) AND IBF) < > 0); 

END; 

OUTPUT (UPI$0$COMMAND) = INITPF; 

/• LOAD INITIAL PARAMETERS •/ 
DO 1=0 TO 5; 

DO WHILE { (INPUT (UPI$0$STATUS) AND IBF) < > 0); 

END; 

OUTPUT (UPI$0$DATA)=INIT$0$TABLE(l); 
END; 

/• TERMINATE PARAMETER LOADING •/ 

DO WHILE ( (INPUT (UPI$0$STATUS) AND IBF) < > 0); 

END; 

OUTPUT (UPI$0$COMMAND)=PAUSE; 

/• START FREQUENCY FUNCTION •/ 

DO WHILE ( (INPUT UPI$0$STATUS) AND IBF) < > 0); 

END; 

OUTPUT (UPI$0$COMMAND)=LOOP; 



Figure 18. IDP Initialization 
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When all required data parameters have been sent, 
the data portion of the initialization is terminated 
by sending a PAUSE command as shown in 
Figure 18. Note how, in each case before data or a 
command is sent, we wait until the input buffer is 
empty. Finally, the initialization is completed 
when we have sent the LOOP command. The 
processor will now be generating an output 
frequency as specified by the parameters. 

Remember that, according to our earlier discus- 
sion and as we have shown in Figure 12, the 
unused output ports should be set to a logical low 
condition to allow the use of those lines as inputs to 
carry additional data into the controller. This 
should be done as a part of the initialization 
process. The secondary utility command, CLRP2 
is used for this purpose. This process is illustrated 
in Figure 19. 

We should next direct our attention to establishing 
a software interface which will take the desired 



weighbelt speed term and convert it to a frequency 
output suitable to drive the motor translator. We 
know that this will involve selecting a particular 
scale factor and period term which will generate 
the correct waveform. Previously, we established 
that, for a maximum frequency of 550 hertz, we 
need to establish a period of 1.82 milliseconds. 
Many combinations of Scale Factor and Period 
parameter will generate this time interval. Ideally, 
the smallest increment of change can be estab- 
lished by setting a constant period and modifying 
the scale factor. If we make some calculations, we 
will find that the fact that the scale factor is a byte 
value (giving us a range of between and 255) 
limits the frequency range which can be produced 
using any one value for a period. It seems that we 
will be forced to vary both the period and the scale 
factor as a function of the desired frequency. 

In Figure 20, we have plotted the frequency output 
for various values of Scale Factor and Period. Our 
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/• SET UNUSED BITS TO ALLOW EXPANSION •/ 

DO WHILE ( (INPUT UPI$0$STATUS) AND IBF) < > 0); 

END; 

OUTPUT (UPI$0$COMMAND)=CLRP2; 

DO WHILE ( (INPUT (UPI$0$STATUS) AND IBF) < > 0); 

END 

OUTPUT (UPI$0$DATA)=INITIAL$OUTPUT; 

Figure 19. Secondary Utility Command 
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intent is to maintain the highest resolution 
possible for the desired output range of 50 to 550 
hertz. Choosing four period base parameters will 
provide us with acceptable waveform generation 
characteristics. We will choose the data sets of 
Figure 21 based upon the data shown in Figure 20. 

The Period can be determined by examining the 
desired frequency range. The scale factor can be 
calculated from the equation: 

SF = 10,000 / ( (FREQUENCY) x (PERIOD) ) 

Again, the PL/M-80 language program to imple- 
ment the interface between the host and the IDP is 
easily constructed. For example. Figure 22 
provides the- code which will be required to 
determine the appropriate Period parameter and 
also illustrates the use of FSP programs to handle 



the mathematical calculations required to deter- 
mine the corresponding scale factor. 

The principles above can be expanded into a 
complete interface package to offload the host 
processor of the need to generate the frequency 
waveform to the translator of the weighbelt 
motor. The complete program for the processor 
can be found in Appendix A. 

Weight Input Processor 

The second use of an iSBC 941 Processor is to 
provide the capability of converting the high 
frequency inputs from the weight sensor of the 
weighbelt into a digital value equivalent to the 
actual weight on the belt. This frequency to digital 
conversion can be easily accomplished by the use 
of the Primary Function, FCOUNT. 



Frequency 




Period Scale Factor 


Resolution 


. 50 to 165 Hz. 




9 221 to 67 


3 Hz. 


166 to 225 Hz 




5 121 to 89 


3 Hz. 


226 to 285 Hz, 




3 147 to 117 


3 Hz. 


286 to 550 Hz. 




2 175 to 91 
Figure 21. FREQ Output Ranges 
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/• COMPUTATION OF FREQUENCY RANGE •/ 
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IF FREQ < 285 
THEN DO; 
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IF FREQ < 226 
THEN DO; 
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IF FREQ < 166 
THEN RANGE = 9; 
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ELSE RANGE = 5; 
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END; 
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ELSE RANGE = 3; 
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END; 
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ELSE RANGE = 2; 





68 



69 



72 



73 4 

74 4 

75 4 



/• LOAD MATH ACCUMULATOR WITH 100,000 •/ 
CALL MQULD4 (.IR,.HUNDRED$K); 

/• TEST FOR MOTOR SHUTDOWN •/ 
IF FREQ>1 
THEN DO; 

/• DIVIDE BY FREQUENCY •/ 

CALL MQUDV2 (.IR,.FREQ); 

/• DIVIDE BY RANGE FACTOR •/ 

CALLMQUDV1 (.IR.. RANGE); 

/• GET TWO'S COMPLEMENT FOR ISBC 941 SCALE FACTOR •/ 
CALL MQUST1 (.IR,.FREQA); 
FREQA=NOT (FREQA + 1); 
END; 



Figure 22. Period and Scale Factor Computations 
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The FCOUNT Primary Function is selected by 
sending the INITPF command followed by four 
parameters. The process is identical to that which 
was used in the previous example when we 
established the FREQ function. In this case, the 
sequence is described in the manual as is shown in 
Figure 23. 



Description 


Command/Data 


Request INIT 
Select FCOUNT 
Input Select 
Output Enable 
Sampling Interval 
Request PAUSE 



D 
D 
D 
D 




Figure 23. FCOUNT Initialization 



Let us examine the derivation of the terms which 
must make up the data table which will be 
transmitted to the processor in order to initialize 
it. The FCOUNT function does not allow the use 
of an external clock so we have no option as to 
which command will be sent to select this 
function. It is defined to be equal to 33H. This 
becomes the first element of the byte array used to 
contain the initial data. 

The Input Select parameter describes which of the 
Port 1 inputs are to be measured. If we refer to 
Figure 13, we can see that a hardware assignment 
of Port 10 has been made for this function. This 
assignment corresponds to bit of the parameter 
being set to a value of 1. The byte value for this 
parameter then becomes OIH. 

The Output Enable byte is used to enable an output 
port corresponding with the input to change states 
when the Sampling Interval time has elapsed. Our 
system has a requirement to operate the control 
algorithm once each 200 milliseconds and we have 
previously indicated that the frequency counter 
would be used to establish this time interval. If the 
output is enabled and connected to an interrupt 
line, it will provide our system with the required 
pacer clock. The output bit from Port 20 will then 
be enabled to provide the interrupt. The para- 
meter for this byte will be set to the same value as 
the Input Select and becomes OIH. 

The Sampling Interval will establish the time 
interval to be used when sampling the input 
frequency. This time interval should be set to 200 



milliseconds for our application. The parameter is 
then calculated from the equation: 

INTERVAL = (SAMPLE PERIOD) / (0.02222) 

OR 

INTERVAL = (0.200) / (0.02222) = 9 

The correct sampling interval for our control 
system should be set to a value of 09H. 

A similar procedure can be used to send this data 
to the processor. The actual code used to imple- 
ment the system can be found in Appendix 
A. Note that the unused bits of the device have 
been set to a predetermined value as was indicated 
by our hardware design of Figure 13. 

Once the processor has been initiated and is 
performing its function, we need only wait until 
the device signals us that the 200 millisecond time 
interval has passed and that it is ready with the 
belt weight. When this interrupt occurs, we will 
read the data and perform our control functions. 
An interface must be established between the 
control algorithm and the processor which 
enables it to receive a value which represents the 
actual weight. 

The total count received by the processor is 
available as a sixteen bit count made up of two 
eight bit bytes. The use of the Secondary Utility 
Commands, Read FCOUNT Measurements 
(RDFCO-RDFCF) allow the two bytes to be 
transferred into the host processor. We are using 
the first counter so we will use the corresponding 
commands, RDFCO and RDFCl. An example of 
the procedure to read one of the count bytes can be 
seen in Figure 24. 

The counter can be commanded to begin its next 
sample period by issuing a LOOP command to the 
processor. The two data bytes can be combined to 
form a 16-bit word and the resultant value divided 
by 2 to form a weight value. The division by two to 
obtain weight is required since the count range 
from to 2000 corresponds to a weight of between 
and 10.00 pounds; thus, each count has a value of 
0.005 pounds. The integer numbers used in the 
control algorithm are fixed point with an implied 
scale factor of 100. The division by two provides a 
result which meets the criteria. 
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106 


2 


107 


3 


108 


2 


109 


2 


110 


3 


111 


2 



/• GET INPUT COUNT LOW BYTE •/ 

DO WHILE ( (INPUT (UPI$1$STATUS) AND IBF) < > 0); 

END; 

OUTPUT (UPI$1$C0MMAND) = RDFCO; 

DO WHILE ( (INPUT$1$STATUS) AND OBF) = 0); 

END; 

LCOUNT = INPUT (UPI$1$DATA); 

Figure 24. FCOUNT Read Procedure 



Appendix A provides the complete listing of the 

code which was used to interface with the 

processor assigned to the primary function, 

FCOUNT. 

Stepper Motor Control Processor 

The third example of utilizing the iSBC 941 
Processor in an industrial application is provided 
by the processor installed into OBS socket 2. This 
device is used to drive a stepper motor which, in 
turn, controls the liquid valve position. Again, we 
will break the discussion into an initialization and 
an interface operational mode. 

We find that the User's Guide indicates that 
initiaUzation to the STEPPER Primary Function 
is performed by sending the INIT command 
followed by up to 21 data bytes. Figure 25 
provides the table which shows the necessary 
parameters for this mode. 

The technique used to place the processor into the 
desired function is the same as we have seen with 
the two other processors so we will not spend time 
dealing with the communications sequence. In- 
stead, we will examine the techniques which can 
be used to determine the values of the initializa- 
tion parameter bytes. 

STEPPER is requested by sending a data byte of 
either 17H or 97H following the INIT command. 
Remember that the significance of setting bit 7 of 
the data high is to request that an external clock 
be used by the processor. There is no reason to use 
an external clock for our application, so we can 
choose a function request byte of 17H. 

The remainder of the data is used to define the 
waveforms which are necessary to drive the 
stepper motor. We will derive the values for these 
parameters by beginning with the manufacturer's 
data sheet and moving until we have determined 
the correct value for each byte of data. 

The motor chosen for this application utilizes four 
phases to drive the shaft. The data sheet provided 



Description 


Command/Data 


Request INIT 


C 


Select STEPPER 


D 


Select Scale Factor 


D 


Output Enable 


D 


Output Polarity 


D 


Common Period 


D 


P20TRAN1 


D 


P20TRAN2 


D 


P21TRAN1 


D 


P21TRAN2 


D 


P22TRAN1 


D 


P22TRAN2 


D 


P23TRAN1 


D 


P23TRAN2 


D 


P24TRAN1 


D 


P24TRAN2 


D 


P25TRAN1 


D 


P25TRAN2 


D 


P26TRAN1 


D 


P26TRAN2 


D 


P27TRAN1 


D 


P27TRAN2 


D 


Request PAUSE 






Figure 25. STEPPER Function Initialization 



information for both a Four-Step Input Sequence 
(1.8 degrees per step) and for an Eight-Step Input 
Sequence (0.9 degrees per step). We will use the 1.8 
degree step angles for our example and applica- 
tion. The data provided by the manufacturer is 
shown in Figure 26. The first task is to convert the 
switch state diagram into a desired waveform for 
each of the four phases. This has been done in 
Figure 27. 

Beginning with Scale Factor, let us determine the 
required data parameters which will yield a 
stepper controller compatible with our motor. The 
Scale Factor will provide the minimum time 
period for one step to take place. The minimum 
time which we can specify is a function of both the 
motor characteristics and of the TRP for the 
primary function, STEPPER. The minimum TRP 
is determined by referencing the IDP User's Guide 
for the desired function. In this case, it is found to 
be 325 + (13 X B) where B is the number of phases 
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RED/WHITE 



< 



DC STEPPING CIRCUIT 



GREEN/WHITE 






FOUR-STEP INPUT SEQUENCE 



STEP 


SW1 


SW2 


SW3 


SW4 


1 


ON 


OFF 


ON 


OFF 


2 


ON 


OFF 


OFF 


ON 


3 


OFF 


ON 


OFF 


ON 


4 


OFF 


ON 


ON 


OFF 


5 


ON 


OFF 


ON 


OFF 



EIGHT-STEP INPUT SEQUENCE 



STEP 


SW1 


SW2 


SW3 


SW4 


1 


ON 


OFF 


ON 


OFF 


2 


ON 


OFF 


OFF 


OFF 


3 


ON 


OFF 


OFF 


ON 


4 


OFF 


OFF 


OFF 


ON 


5 


OFF 


ON 


OFF 


ON 


6 


OFF 


ON 


OFF 


OFF 


7 


OFF 


ON 


ON 


OFF 


8 


OFF 


OFF 


ON 


OFF 


1 


ON 


OFF 


ON 


OFF 



Figure 26. STEPPER Motor Input Sequence 









Figure 27. STEPPER Motor Waveforms 

which are used. The result will be expressed in 
terms of processor cycles and can be converted 
into time by multiplying by 2.71 microseconds per 
cycle. This works out to be: 

325 f (13 X 4) = 377 PROCESSOR CYCLES 

OR 

377 X 2.71 = 1.021 MILLISECONDS 

Now, let's examine the minimum time which can 
be utilized h: '.he stepper motor. This is given in 
the manufactuer's data sheets as being 2.86 milli- 
seconds for the motor which we have chosen to 



use. This value must be used to compute the Scale 
Factor for this application. The Scale Factor is 
computed by dividing the minimum step time by 
86.72 microseconds or: 

SF=2.86 MILLISECONDS/86.72 MICROSECONDS=33 

This number is entered into the processor using 
two's complement which becomes equal to ODFH. 

The Output Enable is used to specify which of the 
eight possible control outputs are to be used to 
control the motor phases. The motor phase 
assignments to I/O ports was made in Figure 15 
and indicates that Ports 24 through 27 will be 
enabled for the primary function. Setting the 
corresponding bits provides a parameter to be sent 
to the processor of OFOH. 

The rest of the parameters deal with providing a 
definition of the waveforms generated in Figure 26 
to the processor. The following paragraphs deal 
with the operations required to convert the 
graphic representation into data parameters. 

Each phase must be initialized to an initial output 
state which corresponds to the signal level shown 
for Step of Figure 27. A ''1" will be placed into 
the bit corresponding to each of the port's output 
bits which are to be in a logical one state upon 
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reaching step 0. We see that Bits 24 and 26 are set 
corresponding to phase 1 and 3. The data byte for 
Initial Output is thus defined to be 050H. 

The Period parameter for a stepper motor function 
corresponds to the number of steps which are 
defined in the motor's step sequence. Our example 
uses a four step sequence so the Common Period 
will be set to a value of 04H. 

The remainder of the initialization parameters 
define the transitions of each of the phases. This 
involves the examination of the waveform and 
noting the points at which the output level 
changes. This data can be input to allow the 
device to accurately produce the control wave- 
forms for any stepper motor control mode. We are 
not using the first four output bits so the transition 
definitions for these outputs is meaningless and 
will be output as zeroes. The waveform for output 
Port 24 shows a transition at steps 1 and 3. The 
parameter for the first transition of Port 24, 
P24TRAN1 is defined to be OOH. Likewise, the 
second transition, P24TRAN2 is set to a value of 
02H. 

The technique used above can be continued to 
defme the constants, P25TRAN1 and P25TRAN2 
as being the same as for Port 24 or OOH and 02H 
respectively. 

The transitions for the phases driven from Port 26 
and 27 can be seen to occur at steps 1 and 3 so the 
data for those parameters can easily be seen to be 
set to OIH and 03H for each port. 

The initialization table can be sent to the 
processor using the same techniques as were used 



for the processors discussed previously. The 
complete program for the initialization can be 
found in Appendix A. 

A driver must next be prepared which will be used 
to provide the interface between the control 
algorithm and the IDP processor which supports 
the stepper motor. When the STEPPER primary 
function is used, a queue is utilized for supporting 
the step commands to the motor. Each command 
to the stepper consists of a data byte signifying the 
step rate to be used and a data byte which provides 
the signed magnitude of the number of steps to be 
moved. Using the motor to control a flow control 
valve allows us to use a constant step rate, but 
some type of program must be prepared which will 
convert the signed two's complement representa- 
tion of the position from the control algorithm to a 
signed magnitude format. 

The number conversion is easily done and the 
PL/M-80 programming code to perform the format 
change is shown in Figure 28. 

The data queue allows up to six movement 
commands to be present and waiting to be 
serviced by the IDP. If the processor is behind in 
its operations and cannot accept a seventh 
request, the host must wait until one of the 
requests in the queue has been serviced. The 
queue status bits can be tested to determine if room 
exists for another command and the ''queue not 
empty" bit can be tested to verify that all 
requested movements have been completed. 
Normal operation of our motor should be such that 
the queue is not allowed to fill to its maximum 
capacity. 



143 



144 4 

145 4 



/• SUPPORT CONVERSION TO SIGNED MAGNITUDE NUMBER •/ 
IF POSITION > 127 
THEN DO; 

/• GET MAGNITUDE OF MOVEMENT •/ 
POSITION = 256 - POSITION; 

/• SET SIGN FOR COW ROTATION •/ 

POSITION = POSITION OR REVERSE; 
END; 



Figure 28. Number Format Conversion 
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The code which is required to test the queue and to 
send a stepper movement request is shown in 
Figure 29. The complete code can be seen in 
Appendix A. 

VIII. APPLICATION SOFTWARE 

Having developed the software which is required 
to support the Industrial Digital Processors, we 
can now devote our time to the task of implement- 
ing the application software and of handling any 
programs which are required to support functions 
unique to the host iSBC 569 board. This software 
can be grouped into two general categories, 
initialization programs, and control algorithm 
programs. 

Initialization Programs 

The initialization of the iSBC 569 involves setting 
up the required configuration of interrupt hand- 
ling and of the devices which are installed into the 
slave sockets. For the purposes of this applica- 
tion, we will include some system diagnostic 
capabilities within the process. These routines 
will be executed each time a RESET or a POWER- 
UP occurs. Only the highlights of the code used 
will be presented in detail; however, the complete 
listings of the initialization programs can be 
found in Appendix A by referring to the BCKGND 
Program listing. 

A unique feature of using the iSBC 941 processors 
is their ability to provide, upon request, an 



identification code. The initiation diagnostic 
program takes advantage of this fact by interro- 
gating each processor and verifying that the 
correct ID code is returned. If any of the proces- 
sors have failed catastrophically or if the internal 
data bus of the host board has failed, the program 
will provide an indication of this fact. 

Each of the slave processors has, associated with 
it, an individual hardware reset line which is 
under the control of the host. A reset or power up 
condition will cause the control lines to reset to the 
state which hold each slave in a reset state. Before 
any slave can be used, it's associated reset line 
must be de-activated. This is done by sending a 
logical one to the corresponding bit of the Reset 
Latch. Other bits of the Reset Latch can jbe used to 
illuminate the on-board LED or to generate an 
interrupt to another board on the Multibus data 
bus. 

A special PL/M-80 command is utilized to disable 
the reset interrupts of the 8085A host processor. 
Execution of this command will allow all servic- 
able interrupts to enter via the 8259A Interrupt 
Controller. The command which will mask off the 
unused interrupt structure is shown in Figure 30. 

The initialization process must also initialize the 
FSP Integer Record. This will allow the use of the 
math support routines which will be required to 
support the control algorithm. 



/• VERIFY THAT QUEUE SPACE IS AVAILABLE •/ 

146 3 DO WHILE ( (INPUT (UPI$2$STATUS) AND QF) < > 0); 

147 4 END; 

/• REQUEST DESIRED STEP RATE •/ 

148 3 DO WHILE ( (INPUT (UPI$2$STATUS) AND IBF) < > 0); 

149 4 END; 

150 3 OUTPUT (UPI$2$DATA) = STEP$RATE; 

/• REQUEST STEPPER MOVEMENT •/ 

151 3 DO WHILE ( (INPUT (UPI$2$STATUS) AND IBF)< >0); 

152 4 END; 

153 3 OUTPUT (UPI$DATA) = POSITION; 



Figure 29. STEPPER Movement Request 



34 1 



/• MASK OUT THE RESET INTERRUPTS OF THE PROCESSOR •/ 
CALL S$MASK (MASKS); 



Figure 30. PL/M-80 Sim Instruction 
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Control Algorithm Programs 

The program which actually handles the control 
algorithm for the two loops can be found in 
Appendix A, MAIN$CONTROL. The flow of the 
program is straightforward and can easily be 
followed by reading the listing. The operations 
are primarily handled by the use of repeated calls 
to the FSP integer math routines and to the 
processor interface modules which we have 
previously generated. 

It is beyond the scope of this application note to 
dwell upon the techniques which were used to 
generate the FID control routine; this aspect will 
be covered in a future application note. 

Limits were placed upon the control outputs so 
that the signals to the processors would not exceed 
the physical limits of the external devices. For 
example, the frequency range is limited to range 
between and 550 to correspond with the 
operating range of the weighbelt as we have 
defined it. The limits upon the liquid control valve 
have been set at plus and minus 10 steps since this 
is the maximum distance which the stepper motor 
can travel in any one 200 millisecond time period; 
increasing the possible count could result in filling 
the queue. This could cause the 200 millisecond 
time to be extended if we had to wait for the queue 
to empty. 

Master Processor 

A complete control solution to the weighbelt feeder 
and the liquid applicator has now been developed. 
The process is stand alone and resides entirely 
upon a single board. It can operate without 
requiring any access from the MULTIBUS bus, 
thus freeing the bus for other control, monitoring 
or supervisory duties. 

The system developed for this application note 
requires a setpoint for the mass flow and a liquid 
ratio be provided to the control system. This 
information would normally be supplied by some 
type of bus master device. We have chosen to use 
the pre-configured RMX/80 BASIC-80 Interpreter 
to perform this task. A simple program needs to 
be prepared which will allow adjustment of the 
setpoints and monitoring of the operation of the 
control system. 

Using BASIC will provide full disk I/O capabil- 
ities to the operator. Communicating with the 



system through a CRT terminal, he can write and 
execute programs which use the resources of the 
system disk or of any of the controllers which may 
be present on the bus. 

Two programs are required to perform this 
task. Since they are written in BASIC, they may 
easily be modified or expanded if the need should 
ever arise. Indeed, other programs could be 
written to perform other tasks, such as optimizing 
the control parameters. 

In both programs, the parameters involved with 
the control operation are accessed by using the 
PEEK and POKE instructions. Remember that 
the iSBC 569 controller allows the on-board 
memory to be made available to other devices on 
the bus through the dual port mechanism. In our 
application, this has been done by jumpering the 
board such that the on-board memory beginning 
at location 8000H can be accessed on the bus at 
location 2000H. This mapping was done since the 
memory locations at 2000H are not used by BASIC 
unless requested to do so. A byte of data which is 
at location 827EH on the controller can be read by 
performing a PEEK of location 227EH. Some of 
the memory assignments for the controller have 
been shown in Figure 31. 



MOD MAINCONTROLMODULE 


829FH 


SYM 


MEMORY 


8233H 


SYM 


PRLQ 


825FH 


SYM 


C0NSTANT$1 


OODCH 


SYM 


B0UNDS2 


00E6H 


SYM 


TIMEINTERVAL 


827AH 


SYM 


LIQUIDFLOW 


00E8H 


SYM 


DISTREV 


8280H 


SYM 


MASSFLOW 


8285H 


SYM 


LIQUIDVALVE 


8288H 


SYM 


DUMMY 


OOEFH 


SYM 


ZERO 


01ADH 


SYM 


PIDRUN 


81F7H 


SYM 


IR 


825DH 


SYM 


LIQCOUNT 


8268H 


SYM 


C0NSTANTS2 


00E4H 


SYM 


C0NTR0L1 


8277H 


SYM 


BELTSPEED 


827CH 


SYM 


MASSSETPOINT 


00E9H 


SYM 


CONVLENGTH 


8282H 


SYM 


BELTCONTROL 


8287H 


SYM 


SYSTEMRUNNING 


828AH 


SYM 


ICW 


3F00H 


SYM 


JUMPTABLE 


8209H 


SYM 


PRCV 


825EH 


SYM 


BELTCOUNT 


00D4H 


SYM 


B0UNDS1 


00E5H 


SYM 


C0NTR0L2 


8278H 


SYM 


BELTWEIGHT 


827EH 


SYM 


SETPOINT 


OOEAH 


SYM 


SIX 


8284H 


SYM 


LIQUIDRATIO 


OOEBH 


SYM 


ERRORFIELD 


OOEDH 


SYM 


THOUSAND 


OOF 1H 


SYM 


INITIATION 


Figure 31. Selected Memory Location Assignments 
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The first program involves setting up the two 
control parameters and handling the control flag 
which causes the process to start and to stop. This 
program can be found in Figure 32. 



10 REM THIS PROGRAM IS USED TO INPUT SETPOINTS 
15 REM TO THE LIQUID CONTROL SYSTEM. 
20 POKE02287H,0 

25 INPUT "ENTER MASS SETPOINT-";MS 

26 IFMS> 1200 THEN 25 
30 MS=CINT(MSx10/60) 
35 H=INT{MS/256) 

40 L=CINT{MS-Hx256) 

45 POKE 0227EH,L 

50 POKE 0227FH,H 

55 INPUT "PERCENT LIQUID-";LR 

60 LR=CINT(LR) 

65 IFLR> 127 THEN 55 

70 POKE 02284H,LR 

75 POKE 02287H,1 

80 RUN "STATUS" 



Figure 32. Basic Program for Parameter Initialization 



Upon completion of the initialization program, a 
second program provides a display of the system 
operation. This program could have been an 
optional program which is only called when the 
operator desires to view the system operation. A 
program which provides a snapshot of the system 
operation is shown in Figure 33. Again, the 
program is interactive with the operator and can 
easily be modified at any time to reformat or 
display additional information. 

IX. CONCLUSION 

The purpose of this application note has been to 
demonstrate some of the techniques which can be 
used to provide a control system design solution 
using an intelligent slave concept. This has been 
done and the system has been constructed and has 
been found to operate as the design specified. The 
Intelligent Slave Concept does provide a single 
board solution to distributed control and certainly 
off-loads the master processor of control duties. 



PROGRAM NAME: STATUS 

10 l=PEEK(0227EH) 

20 H=PEEK(0227FH) 

30 MS=((256xH)+L)x60/10 

40 L=PEEK(02278H) 

50 H=PEEK(02279H) 

60 WT=((256xH)+L)/100 

70 L=PEEK(022890H) 

80 H=PEEK(02281H) 

90 AM=((256xH)+L)x60/10 
100 MT=PEEK(02294H) 
110 LR=(PEEK(02284H))/100 
120 LS=AMxLR 
130 L=PEEK(0227AH) 
140 H=PEEK(0227BH) 
150 LF=((256xH)+L)/100 

160 PRINT "MASS SETPOINT","WEIGHT";'ACTUAL MASS","MOTION" 
170 PRINT MS,WT,AM,MT 

180 PRINT "LIQUID RATIO"/'LIQUID SET","LIQUID FLOW" 
190 PRINT LR.LS.LF 
200 Z=PEEK(02285H) 
210 IFZ< 128 THEN 230 
220 Z=256-Z 
225 Z=0-Z 

230 L=PEEK(02282H) 

231 H=PEEK{02283H) 

232 BS=((256xH)+L)x60/200 

239 PRINT "STEPPER";Z, "BELT";BS 

240 PRINT " " 
250 PRINT " " 

260 FOR N=Oto 1000 
270 NEXT N 
280 GOTO 10 



Figure 33. Basic Snapshot Program 
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This frees the master to provide supervisory situations. At the same time, there is no reason 
control and human interface duties. why the IntelHgent Slave board could not be used 

to provide a single board solution to a simple 
Certainly, this concept can be expanded to control application where no interaction with 
encompass a broad variety of complex control other processes is required. 
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APPENDIX A 
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ISIS-II PL/M-80 V3.1 COMPILATION OF MODULE BACKGROUNDMODULE 
OBJECT MODULE PLACED IN : Fl : BCKGND. OBJ 

COMPILER INVOKED BY: PLM80 : Fl : BCKGND. PLM DEBUG PAGEWIDTH (72 ) 

-CKGROUND PROGRAM') 

* THIS IS THE MAIN BACKGROUND OPERATING * 

* PROGRAM FOR THE PID CONTROL SYSTEM. * 



TITLE( 'BA 



1 BACKGROUND$MODULE: DO; 

/* DECLARATION OF BOARD I/O ASSIGNMENTS */ 

2 1 DECLARE UPI$0$STATUS LITERALLY '0E5H' 

3 1 DECLARE UPI$1$STATUS LITERALLY '0E7H' 

4 1 DECLARE UPI$2$STATUS LITERALLY '0E9H' 



5 
6 
7 



DECLARE UPI$0$COMMAND 
DECLARE UPI$1$C0MMAND 
DECLARE UPI$2^.C0MMAND 



LITERALLY '0E5H' ; 
LITERALLY •0E7H'; 
LITERALLY '0E9H'; 



8 

9 

10 



DECLARE UPI$0$DATA 
DECLARE UPI$1$DATA 
DECLARE UPI$2$DATA 



LITERALLY •0E4H'; 
LITERALLY '0E6H' ; 
LITERALLY 'PESH'; 



11 



DECLARE RESET$LATCH:?ADR 



LITERALLY '0EAH' 



/* DECLARATION OF RAM TEST PARAMETERS */ 



12 


1 


13 


1 


14 


1 


15 


1 


16 


1 


17 


1 


18 


1 


19 


1 


20 


1 


21 


1 


22 


1 



DECLARE BEGIN$RAM 

DECLARE END$RAM 

DECLARE ZERO$PATTERN 

DECLARE ONES$PATTERN 



LITERALLY '8000H' 

LITERALLY '8500H' 

LITERALLY •000H'; 

LITERALLY '0FFH'; 



/* DECLARATION OF RESET LATCH BIT ASSIGNMENTS */ 



DECLARE RESET$UPI$0 

DECLARE RESET$UPI$1 

DECLARE RESET$UPI$2 

DECLARE LIGHT$LED 

DECLARE MULTI$INTR 



LITERALLY 
LITERALLY 
LITERALLY 
LITERALLY 
LITERALLY 



'00000001B' ; 
'00000010B' ; 
•00000100B' ; 
•00001000B'; 
'00010000B* ; 



/* DECLARATION OF ISBC 941 STATUS BITS */ 

DECLARE IBF LITERALLY '00000010BV 

DECLARE OBF LITERALLY '00000001B' 



/* DECLARATION OF ISBC 941 COMMANDS */ 
23 1 DECLARE IDEN LITERALLY '000H'; 



2 4 1 



/* DECLARATION OF ISBC 941 IDENTIFICATION CODE */ 
DECLARE SBC941 LITERALLY •41H'; 



/* DECLARATION OF MEMORY TEST ADDRESS REGISTER */ 

25 1 DECLARE I ADDRESS AT (87FEH); 

26 1 DECLARE MEMLOC BASED I BYTE; 

/* DECLARATION OF RESET MASKS FOR 8085 PROCESSOR */ 
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27 1 DECLARE MASKS BYTE DATA (00FH); 

/* DECLARATION OF PL/M-80 SIM INSTRUCTION */ 

28 1 S$MASK: PROCEDURE (MASK) EXTERNAL; 

29 2 DECLARE MASK BYTE; 

30 2 END S$MASK; 

/* DECLARATION OF INITIATION TASK */ 

31 1 INITIATION: 

PROCEDURE EXTERNAL; 

32 2 END INITIATION; 

/* CLEAR ISBC 941 DEVICES USING ON-BOARD RESET */ 

33 1 OUTPUT (RESET$LATCK$ADR) = 0; 

/* MASK OUT THE RESET INTERRUPTS OF THE PROCESSOR */ 

34 1 CALL S$MASK (MASKS); 

/* TEST MEMORY RAM LOCATIONS */ 
DO I = BEGIN$RAM TO END$RAM; 
MEMLOC = ZERO$PATTERN; 
DO WHILE MEMLOC <> Z ERO$PATTERN ; 
END; 

MEMLOC = ONES$PATTERN; 
DO WHILE MEMLOC <> ONESSPATTERN ; 
END; 
END; 

/* RELEASE 941 LOCKOUT/RESET BITS */ 
43 1 OUTPUT (RESET$LATCH$ADR) = RESET$UPI$0 OR 

RESET$UPI$1 OR 
RESET$UPI$2 OR 
MULTI$INTR; 

/* VERIFY THAT SBC941 PROCESSOR IS IN SOCKET */ 

DO WHILE ((INPUT (UPI $0$STATUS ) AND IBF) <> 0); 

END; 

OUTPUT (UPI$0$COMMAND) = IDEN; 

DO WHILE ((INPUT (UPI $0 $STATUS ) AND OBF) = 0); 

END; 

DO WHILE (INPUT (UPI$0$DATA) <> SBC941); 

END; 

/* VERIFY THAT SBC941 PROCESSOR IS IN SOCKET 1 */ 

DO WHILE ((INPUT (UPI$1 $STATUS ) AND IBF) <> 0); 

END; 

OUTPUT (UPI$1$C0MMAND) = IDEN; 

DO WHILE ((INPUT (UPI$1 $STATUS ) AND OBF) = 0); 

END; 

DO WHILE (INPUT (UPI$1$DATA) <> SBC941); 

END; 



35 


1 


36 


2 


37 


2 


3 8 


3 


39 


2 


40 


2 


41 


3 


42 


2 



4 4 


1 


45 


2 


46 


1 


47 


1 


48 


2 


49 


1 


50 


2 


51 


1 


52 


2 


53 


1 


54 


1 


55 


2 


56 


1 


57 


2 
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58 


1 


59 


2 


60 


1 


61 


1 


62 


2 


63 


1 
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/* VERIFY THAT SBC941 PROCEvSSOR IS IM SOCKET 2 */ 

DO WHILE ((INPUT (UPI$2 $STATUS ) AND IBF) <> 0); 

END; 

OUTPUT (UPI$2$C0MMAND) = IDEM; 

DO WHILE ( (INPUT (UPI $2$STATUS ) AND OBF) = 0); 

END; 

DO WHILE (INPUT (UPI$2$DATA) <> SBC941); 

END; 

/* START-UP TEST OK- TURN OFF LED */ 

65 1 OUTPUT (RESET$LATCH$ADR) = RESET$UPI$0 OR 

RESET$UPI$1 OR 

RESET$UPI$2 OR 

LIGHT$LED OR 
MULTI$INTR; 

/* INITIATE THE CONTROL DEVICES */ 

66 1 CALL INITIATION; 







/* PERFORM BACKGROUND TASKS */ 


67 


1 


DO WHILE 1; 


68 


2 


HALT; 


69 


2 


END; 



70 1 END BACKGROUND$MODULE; 



MODULE INFORMATION: 

CODE AREA SIZE = 00D4H 212D 
VARIABLE AREA SIZE = 0000H 0D 
MAXIMUM STACK SIZE = 0002H 2D 
128 LINES READ 
PROGRAM ERROR (S) 

END OF PL/M-80 COMPILATION 
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ISIS-II PL/M-80 V3.1 COMPILATION OF MODULE MAINCONTROLMODULE 

OBJECT MODULE PLACED IN : Fl : CNTTSK . OBJ 

COMPILER INVOKED BY: PLM80 : Fl : CNTTSK . PLM DEBUG 

$INTVECTOR(4,3F00H) 
$PAGEWIDTH (72) 
$TITLE('MAIN CONTROL') 
/********************•******************************* 

* MAIN$CONTROL$TASK * 

* THIS TASK IS USED TO CONTROL THE TWO PID CONTROL * 

* LOOPS. ONE LOOP CONTROLS THE SPEED OF A CONVEYOR * 

* WHILE THE SECOND CONTROLS THE FLOW OF A LIQUID. * 

* THE TASK OPERATES EACH 200 MSEC. * 

* * 
******** VERSION 1.1 *******************************/ 

1 MAIN$CONTROL$MODULE: DO; 

/* DECLARATION OF PID RECORD SET-UP TASK */ 

2 1 UQPSET: 

PROCEDURE (PR$PTR,ERROR$FLD$PTR,PRIV$PTR) EXTERNAL 

3 2 ' DECLARE (PR$PTR, ERROR$FLD$PTR , PRIVSPTR) ADDRESS; 

4 2 END UQPSET; 

/* DECLARATION OF PID CONTROL BITS */ 

5 1 UQPSCT: 

PROCEDURE (PR$PTR,CONTROL$PTR) EXTERNAL; 

6 2 DECLARE (PR$PTR, CONTROL$PTR) ADDRESS; 

7 2 END UQPSCT; 

/* PROCEDURE TO SET UP PID CONSTANTS */ 

8 1 UQPSCN: 

PROCEDURE (PR$PTR,CONSTANT$PTR) EXTERNAL; 

9 2 DECLARE (PR$PTR, CONSTANT$PTR) ADDRESS; 

10 2 END UQPSCN; 

/* DEFINE THE DEFAULT ERROR HANDLER */ 

11 1 UQPSBD: 

PROCEDURE (PR$PTR,BOUND$PTR) EXTERNAL; 

12 2 DECLARE (PR$PTR , BOUND$PTR) ADDRESS; 

13 2 END UQPSBD; 

/* PROCEDURE TO CHANGE THE TIME INTERVAL */ 

14 1 UQPSTI: 

PROCEDURE (PR$PTR,TIME$INTERVAL$PTR) EXTERNAL; 

15 2 DECLARE (PR$PTR,TIME$INTERVAL$PTR) ADDRESS; 

16 2 END UQPSTI; 

/* DECLARATION OF THE PID CONTROL PROGRAM */ 

17 1 UQPPID: 

PROCEDURE (PR$PTR, IR$PTR) EXTERNAL; 

18 2 DECLARE (PR$PTR , IR$PTR) ADDRESS; 

19 2 END UQPPID; 
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/* DECLARATION OF WEIGHBELT SPEED INTERFACE */ 
WEIGHBELT$SPEED: 

PROCEDURE BYTE EXTERNAL; 
END WEIGHEELT$vSPEED; 

/* DECLARATION OF WEIGHBELT WEIGHT INTERFACE */ 
WEIGHBELT$WEIGHT: 

PROCEDURE ADDRESS EXTERNAL; 
END WEIGHBELT$WEIGHT; 

/* DECLARATION OF LIQUID FLOW RATE INTERFACE */ 
LIQUID$FLOW$RATE: 

PROCEDURE ADDRESS EXTERNAL; 
END LIQUID$FLOW$RATE; 

/* DECLARATION OF WEIGHBELT MOTOR DRIVE INTERFACE */ 

26 1 WEIGHBELT$MOTOR$DRIVE: 

PROCEDURE (SPEED) EXTERNAL; 

27 2 DECLARE SPEED ADDRESS; 

28 2 END WEIGHBELT$MOTOR$DRIVE; 

/* DECLARATION OF LIQUID VALVE INTERFACE */ 

29 I LIQUID$VALVE$POSITION: 

PROCEDURE (POSITION) EXTERNAL; 
DECLARE POSITION BYTE; 
END LIQUID$VALVE$PCSITION; 

/* DECLARATION OF PROCESSOR INITIALIZATION MODULE */ 
PROCESSOR$0$INITIALIZATION : 
PROCEDURE EXTERNAL; 
END PROCESSOR$0$INITIALIZATION; 

/* DECLARATION OF PROCESSOR 1 INITIALIZATION MODULE */ 
PR0CESS0R$1$ INITIALIZATION: 
PROCEDURE EXTERNAL; 
END PR0CESS0R$1$INITIALIZATI0N; 

/* DECLARATION OF PROCESSOR 2 INITIALIZATION MODULE */ 
PR0CESS0R$2$INITIALIZATI0N : 
PROCEDURE EXTERNAL; 
END PR0CESS0R$2$INfITIALIZATI0N; 

/* DECLARATION OF PIT COUNTER 1 INITIALIZATION */ 
C0UNTER$1$ INITIALIZATION: 
PROCEDURE EXTERNAL; 
END C0UNTER$1$INITIALIZATI0N; 

/* DECLARATION OF PIT COUNTER 2 INITIALIZATION */ 
C0UNTER$2$INITIALIZATI0N: 
PROCEDURE EXTERNAL; 
END C0UNTER$2$INITIALIZATI0N; 
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/* DECLARATION OF FSP UNSIGNED LOAD PROCEDURES */ 
MQULDl: PROCEDURE (IR$PTR, VALUE$PTR) EXTERNALS- 
DECLARE (IR$PTR,VALUE$PTR) ADDRESS; 
END MQULDl; 
MQULD2: PROCEDURE ( IR$PTR, VALUE$PTR ) EXTERNAL; 

DECLARE (IR$PTR,VALUE$PTR) ADDRESS; 
END MQULD2; 

/* DECLARATION OF FSP UNSIGNED MULTIPLY PROCEDURE ^ 
MQUMLl: PROCEDURE (IR$PTR , VALUE$PTR) EXTERNAL; 
DECLARE (IR$PTR,VALUE$PTR) ADDRESS; 
END MQUMLl; 
MQUML2: PROCEDURE ( IR$PTR, VALUE$PTR) EXTERNAL; 
DECLARE (IR$PTR,VALUE$PTR) ADDRESS; 
END MQUML2; 

/* DECLARATION OF FSP UNSIGNED DIVIDE PROCEDURE */ 
MQUDVl: PROCEDURE (IR$PTR, VALUE$PTR) EXTERNAL; 

DECLARE (IR$PTR,VALUE$PTR) ADDRESS; 

END MQUDVl; 
MQUDV2: PROCEDURE (I R$PTR, VALUE$PTR) EXTERNAL; 

DECLARE (IR$PTR,VALUE$PTR) ADDRESS; 

END MQUDV2; 

/* DECLARATION OF FSP SIGNED DIVIDE PROCEDURE */ 

MQSDVl: PROCEDURE (IR$PTR, VALUE$PTR) EXTERNAL; 
DECLARE (IR$PTR,VALUE$PTR) ADDRESS; 
END MQSDVl; 
MQSDV2: PROCEDURE (IR$PTR , VALUE$PTR) EXTERNAL; 
DECLARE (IR$PTR,VALUE$PTR) ADDRESS; 
END MQSDV2; 

/* DECLARTATION OF FSP SIGNED STORE PROCEDURE */ 

MQSST2: PROCEDURE (IR$PTR, VALUE $PTR ) EXTERNAL; 
DECLARE (IR$PTR,VALUE$PTR) ADDRESS; 
END MQSST2; 

/* DECLARATION OF FSP SIGNED LOAD PROCEDURE */ 

MQSLD2: PROCEDURE (IR$PTR, VALUE$PTR) EXTERNAL; 
DECLARE (IR$PTR,VALUE$PTR) ADDRESS; 
END MQSLD2; 

/* DECLARATION OF FSP SIGNED SUBTRACT PROCEDURE */ 
MQSSB2: PROCEDURE (IR$PTR, VALUE$PTR) EXTERNAL; 
DECLARE (IR$PTR,VALUE$PTR) ADDRESS; 
END MQSSB2; 

/* DECLARATION OF FSP UNSIGNED STORE PROCEDURE */ 
MQUSTl: PROCEDURE (IR$PTR , VALUE $PTR) EXTERNAL; 

DECLARE (IR$PTR,VALUE$PTR) ADDRESS; 

END MQUSTl; 
MQUST2: PROCEDURE (IR$PTR, VALUESPTR ) EXTERNAL; 

DECLARE (IR$PTR,VALUE$PTR) ADDRESS; 

END MQUST2; 
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/* DECLARATION OF FSP SIGNED MULTIPLY PROCEDURE */ 

81 1 MQSMLl: PROCEDURE ( IR$PTR, VALUE $PTR) EXTERNAL; 

82 2 DECLARE ( IR$PTR, VALUE$PTR ) ADDRESS; 

83 2 END MQSMLl; 

$EJECT 

/*******Vk-**************** ****************** 

* DATA STORAGE AREAS FOR THE PID CONTROL * 
******************************************/ 

/* DEFINITION OF LIMITATION CONSTANTS */ 

DECLARE MAX$MOTOR$SPEED LITERALLY '550*; 

DECLARE MIN$MOTOR$SPEED LITERALLY '0*; 

DECLARE MAX$VALVE$MOVEMENT LITERALLY '10'; 

DECLARE MIN$VALVE$MOVEMENT LITERALLY '-10'; 

/* DEFINITION OF PID PARAMETER COEFFICIENTS */ 

DECLARE FEEDER$C0 LITERALLY '1' 

DECLARE FEEDER$C1 LITERALLY '1' 

DECLARE FEEDER$C2 LITERALLY '1' 

DECLARE FEEDER$C3 LITERALLY '1' 

DECLARE FEEDER$TIME$INTERVAL LITERALLY '1' 

DECLARE FEEDER$SCALE$FACTOR LITERALLY '1' 

DECLARE LIQUID$C0 LITERALLY '1' 

DECLARE LIQUID$C1 LITERALLY '1' 

DECLARE LIQUID$C2 LITERALLY '1' 

DECLARE LIQUID$C3 LITERALLY '1' 

DECLARE LIQUID$TIME$INTERVAL LITERALLY '1' 

DECLARE LIQUID$SCALE$FACTOR LITERALLY '10'; 

/* DEFINITION OF RESET LATCH PARAMETERS */ 

DECLARE RESET$LATCH$ADR LITERALLY '0EAH'; 
DECLARE INDICATOR$ON LITERALLY '07H'; 

DECLARE INDICATOR$OFF LITERALLY '0FH'; 

/* RESERVE 18 BYTES FOR THE INTEGER RECORD */ 

103 1 DECLARE IR (18) BYTE PUBLIC; 

/* RESERVE 42 BYTES FOR EACH PID RECORD */ 

104 1 DECLARE PRCV (4 2) BYTE; 

105 1 DECLARE PRLQ (42) BYTE; 

/* RESERVE SPACE FOR COUNTER DATA */ 

106 1 DECLARE (LIQ$COUNT, BELT$COUNT) BYTE PUBLIC; 

/* RESERVE 12 BYTES FOR EACH CONSTANT ARRAY */ 

107 1 DECLARE CONSTANTSl STRUCTURE ( 

C0 ADDRESS, 

CI ADDRESS, 

C2 ADDRESS, 

C3 ADDRESS, 

DT ADDRESS, 

S ADDRESS ) ; 
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108 1 DECLARE C0NSTANTS2 STRUCTURE ( 

C0 ADDRESS, 

CI ADDRESS, 

C2 ADDRESS, 

C3 ADDRESS, 

DT ADDRESS , 

S ADDRESS ) ; 

/* RESERVE 8 BYTES FOR EACH BOUNDS ARRAY */ 

109 1 DECLARE BOUNDS! (4) ADDRESS DATA ( 

000H, 
000H, 

MAX$MOTOR$SPEED, 
MIN$MOTOR$SPEED ) ; 

110 1 DECLARE B0UNDS2 (4) ADDRESS DATA ( 

000D, 

000D, 

MAX $VALVE $MOVEMENT , 

MIN$VALVE$MOVEMENT ) ; 

/* RESERVE 1 BYTE FOR EACH CONTROL BYTE *"/ 

111 1 DECLARE CONTROLl BYTE DATA (073H); 

112 1 DECLARE C0NTR0L2 BYTE DATA (053H); 

/* DECLARE TIME INTERVAL */ 

113 1 DECLARE TIME$INTERVAL ADDRESS DATA (1); 

/* RESERVE SPACE FOR THE CURRENT BELT SPEED */ 

114 1 DECLARE BELT$SPEED BYTE; 

/* RESERVE SPACE FOR THE CURRENT BELT WEIGHT */ 

115 1 DECLARE BELTSWEIGHT ADDRESS; 

/* RESERVE SPACE FOR THE LIQUID FLOW */ 

116 1 ' DECLARE LIQUID$FLOW ADDRESS; 

/* RESERVE SPACE FOR THE EFFECTIVE SETPOINT */ 

117 1 DECLARE MASS$SETPOINT ADDRESS; 

/* RESERVE SPACE FOR THE DESIRED SETPOINT */ 

118 1 DECLARE SET$POINT ADDRESS; 

/* RESERVE SPACE FOR THE DISTANCE OF BELT PER REVOLUTION 
V 

119 1 DECLARE DIST$REV BYTE DATA (100); 

/* DEFINE THE CONVEYOR LENGTH */ 

120 1 DECLARE CONV$LENGTH BYTE DATA (200); 

/* DEFINE THE CONSTANT SIX */ 

121 1 DECLARE SIX BYTE DATA (6); 

/* RESERVE STORAGE FOR ACTUAL CURRENT MASS FLOW */ 

122 1 DECLARE MASS$FLOW ADDRESS; 
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/* RESERVE SPACE FOR BELT CONTROL OUTPUT */ 

123 1 DECLARE BELT$CONTROL ADDRESS; 

/* RESERVE SPACE FOR LIQUID RATIO */ 

124 1 DECLARE LIQUID$RATIO BYTE; 

/* RESERVE SPACE FOR LIQUID CONTROL OUTPUT */ 

125 1 DECLARE LIQUID$VALVE ADDRESS; 

/* RESERVE SPACE FOR RUN/HALT CONTROL */ 

126 1 DECLARE SYSTEM$RUNNING BYTE PUBLIC; 

/* RESERVE SPACE FOR ERROR FIELD */ 

127 1 DECLARE ERROR$FIELD ADDRESS DATA (0F800H); 

128 1 DECLARE DUMMY ADDRESS; 

/* RESERVE SPACE FOR PIC ICW BYTE */ 

129 1 DECLARE ICW BYTE; 

/* DEFINE CONSTANT 1000 */ 

130 1 DECLARE THOUSAND ADDRESS DATA (1000); 

/* DEFINE CONSTANT */ 

131 1 DECLARE ZERO ADDRESS DATA (0); 

/* DEFINE INTERRUPT JUMP TABLE */ 

132 1 DECLARE JUMP$TABLE BYTE AT (3F00H); 

/* DECLARATION OF PIC ADDRESSES ON ISBC 569 BOARD */ 

133 1 DECLARE PIC$ICW1$PTR LITERALLY •0ECH'; 

134 1 DECLARE PIC$ICW2$PTR LITERALLY ' 0EDH ' ; 

135 1 DECLARE PIC$INT$MASK$PTR LITERALLY '0EDH'; 

/* DECLARATION OF PIC CONSTANTS */ 

136 1 DECLARE CLR$LOW$BITS LITERALLY '0E0H'; 

137 1 DECLARE INTERVAL$4 LITERALLY •016H'; 

138 1 DECLARE INTERRUPT$MASK LITERALLY *0F4H'; 

$EJECT 

* INITIALIZE PROGRAM AT START-UP OF SYSTEM * 

* THIS PROCEDURE IS GALLED AT START-UP * 
***********•*******************************/ 

139 1 INITIATION: PROCEDURE PUBLIC; 

/* DISABLE THE INTERRUPTS */ 

140 2 DISABLE; 

/* INITIALIZE PID RECORD */ 

141 2 CALL UQPSET (. PRCV, . ERROR$FIELD, .DUMMY) ; 

142 2 CALL UQPSET (. PRLQ ,. ERROR$FIELD, . DUMMY ) ; 
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/* INITIALIZE THE CONTROL BITS */ 
1^3 2 CALL UQPSCT ( . PRCV , . CONTROLl ) ; 

144 2 CALL UQPwSCT ( . PRLQ, . C0NTR0L2 ) ; 



/* SET UP THE PID CONSTANTS */ 



145 
146 
147 
.14 8 
149 
150 

151 
152 
153 
154 
155 
156 



2 
2 
2 
2 
2 
2 

2 
2 
2 
2 
2 
2 



CONSTANTS 1.C0 
CONSTANTS! .CI 
CONSTANTS 1.C2 
C0NSTANTS1.C3 
CONSTANTS l.DT 
CONSTANTS! .S 

CONSTANTS2.C0 
CONSTANTS 2. CI 
C0NSTANTS2.C2 
CONSTANTS2.C3 
CONSTANTS 2. DT 
CONSTANTS 2. S 



FEEDER$C0j 

FEEDER$C1; 

FEEDER$C2; 

FEEDER$C3; 

FEEDER$TIME$INTERVAL; 

FEEDER$SCALE$ FACTOR; 

LIQUID$C0; 

LIQUIDSCl; 

LIQUID$C2; 

LIQUID$C3; 

LIQUID$TIME$INTERVAL ; 

LIQUID$SCALE$FACTOR; 



/* CLEAR SETPOINTS */ 

157 2 SETPOINT = 0; 

158 2 LIQUID$RATIO = 0; 

159 2 SYSTEM$RUNNING = 0; 

/* INITIALIZE THE CONSTANTS */ 

160 2 CALL UQPSCN (. PRCV, • CONSTANTS 1 ) ; 

161 2 CALL UQPSCN ( . PRLQ, . C0NSTANTS2 ) ; 

/* INITIALIZE THE BOUNDS */ 

162 2 CALL UQPSBD (. PRCV, . BOUNDS! ) ; 

163 2 CALL UQPSBD (. PRLQ ,. BOUNDS 2 ) ; 

/* SET THE TIME INTERVAL */ 

164 2 CALL UQPSTI ( . PRCV, . TIME$INTERVAL) ; 

165 2 CALL UQPSTI ( . PRLQ, . TIME$INTERVAL) ; 



166 



/* INITIALIZE PROCESSOR */ 

CALL PROCESSOR$0$ INITIALIZATION; 



167 

168 



/* INITIALIZE PROCESSOR 1 */ 

CALL PR0CESS0R$1$ INITIALIZATION; 

/* INITIALIZE PROCESSOR 2 */ 

CALL PR0CESS0R$2$INITIALIZATI0N; 



169 



/* INITIALIZE COUNTER 1 */ 

CALL C0UNTER$1$INITIALIZATI0N; 



170 



171 



172 



/* INITIALIZE COUNTER 2 */ 

CALL C0UNTER$2$INITIALIZATI0N; 

/* INITIALIZE INTERRUPT CONTROLLER */ 
ICW = (LOW ( . JUMP$TABLE) AND 
CLR$LOW$BITS ) OR 
INTERVALS 4 ; 
OUTPUT (PIC$ICW1$PTR) = ICW; 
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ICW = HIGH (.JUMP$TAELE) ; 
OUTPUT (PIC$ICW2$PTR) = ICW; 

/* SET INTERRUPT MASKS */ 

OUTPUT (PIC$INT$MASK$PTR) = INTERRUPT$MASK ; 

/* ENABLE INTERRUPTS */ 
ENABLE; 

/* RETURN TO MAIN PROGRAM */ 
RETURN; 

END INITIATION; 

$ EJECT 
/•***********•*******************************•****** 

* THIS IS THE PID CONTROL ROUTINE. IT IS ENTERED * 

* EACH 200 MILLISECONDS THROUGH AN INTERRUPT GEN- * 

* ERATED BY THE FREQUENCY COUNTER UPI AND SENT TO * 

* INTERRUPT 3. * 



179 1 PIDRUN: PROCEDURE INTERRUPT 3 PUBLIC; 

/* TURN THE LED INDICATOR ON */ 

180 2 OUTPUT (RESET$LATCH$ADR) = INDICATOR$ON ; 

/* GET WEIGHBELT WEIGHT */ 

181 2 BELT$WEIGHT=WEIGHBELT$WEIGHT; 

/* GET LIQUID FLOW RATE */ 

182 2 LIQUID$FLOW=LIQUID$FLOW$RATE; 

/* CONTROL START-STOP RAMP */ 

183 2 IF SYSTEM$RUNNING 

THEN MASS$SETPOINT=SETPOINT; 

185 2 ELSE MASS$SETPOINT=0; 

/* DETERMINE ACTUAL MASS FLOW ON WEIGHBELT */ 

186 2 CALL MQULD2(.IR, .BELT$CONTROL) ; 

187 2 CALL MQUML2 (.IR, .BELTSWEIGHT) ; 

188 2 CALL MQUMLl ( . IR, •DIST$REV) ; 

189 2 CALL MQUDVl (. IR, .CONV$LENGTH) ; 

190 2 CALL MQSDV2 (.IR, .THOUSAND) ; 

191 2 CALL MQSST2(. IR,.MASS$FLOW) ; 

/* COMPUTE ERROR SIGNAL ON WEIGHBELT */ 

192 2 CALL MQSLD2(.IR; .MASS$SETPOINT); 

193 2 CALL MQSSB2 ( .IR, .MASS$FLOW) ; 

/* HANDLE PID BELT CONTROL ALGORITHM */ 

194 2 CALL UQPPID(.PRCV, .IR) ; 

/* STORE OUTPUT SIGNAL */ 

195 2 CALL MQUST2 (.IR, .BELT$CONTROL) ; 
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/* COMPUTE LIQUID SETPOIMT */ 

CALL MQSLD2(.IR, .MASS$FLOW) ; 
CALL MQS.MLl (.IR, . LIQUID$RATIO ) ; 
CALL MQSMLl (.IR^.SIX) ; 

/* VERIFY THAT WEIGHBELT IS MOVING */ 
199 2 IF WEIGHBELT$SPEED = 

THEN CALL MQULD2 ( . IR, , ZERO ) ; 

/* COMPUTE LIQUID ERROR */ 

201 2 CALL MQSSB2( .IR, .LIQUID$FLOW) ; 

/* HANDLE PID LIQUID CONTROL */ 

202 2 CALL UQPPID(.PRLQ, .IR); 

/* STORE OUTPUT SIGNAL */ 

203 2 CALL MQUSTl (.IR, .LIQUID$VALVE) ; 

/* OUTPUT WEIGHBELT CONTROL SIGNAL */ 

204 2 CALL WEIGHBELT$MOTOR$DRIVE (BELT$CONTROL ) ; 

/* OUTPUT FLOW CONTROL SIGNAL */ 

205 2 CALL LIQUID$VALVE$POSITION (LIQUID$VALVE ) ; 

/* SEND END OF INTERRUPT TO 8259 CONTROLLER */ 

206 2 OUTPUT (0ECH)=020H; 

/* TURN THE LED INDICATOR OFF */ 

207 2 OUTPUT (RESET$LATCH$ADR) = INDICATOR$OFF ; 







/* RETURN FROM CONTROL TASK */ 


208 


2 


RETURNS- 


209 


2 


END PIDRUN; 


210 


1 


END; 



MODULE INFORMATION: 

CODE AREA SIZE = 01C1H 44 9D 
VARIABLE AREA SIZE = 0094H 148D 
MAXIMUM STACK SIZE = 000AH 10D 
465 LINES READ 
PROGRAM ERROR (S) 

END OF PL/M-80 COMPILATION 



3-107 



ISIS-II PL/M-80 V3.1 COMPILATION OF MODULE PROCESSORINITIALIZATIONMODULE 
OBJECT MODULE PLACED IN : Fl : SBC941 . OBJ 

COMPILER INVOKED BY: PLM80 : Fl : SBC94 1 . PLM DEBUG PAGEWIDTH (72 ) TITLE ("PR 

-OCESSOR INITIALIZATION') 



* THIS PROGRAM IS USED TO INITIALIZE THE ISBC * 

* 941 PROCESSOR INSTALLED IN SOCKET 0. THE * 

* DEVICE WILL OPERATE IN THE FREQUENCY OUTPUT * 

* MODE. * 



PROCESSOR $INITIALIZATION$MODULE: DO; 
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/* DECLARATION OF ADDRESSES */ 

DECLARE UPI$0$STATUS LITERALLY *0E5H* 

DECLARE UPI$0$COMMAND LITERALLY »0E5H' 

DECLARE UPI$0$DATA LITERALLY •0E4H* 



DECLARE UPI$1$STATUS 

DECLARE UPI$1$C0MMAND 

DECLARE UPI$1$DATA 

DECLARE UPI$2$STATUS 

DECLARE UPI$2$C0MMAND 

DECLARE UPI$2$DATA 



LITERALLY •0E7H' 
LITERALLY '0E7H' 
LITERALLY •0E6H* 



DECLARATION OF ISBC 

DECLARE SETPl 

DECLARE CLRPl 

DECLARE CLRP2 

DECLARE PAUSE 

DECLARE LOOP 

DECLARE INITPF 

DECLARE PACIFY 

DECLARE ENFLAG 



941 



/* DECLARATION OF 
DECLARE RFC 
DECLARE IBF 
DECLARE QF 



ISBC 941 



LITERALLY 


•0E9H' 


, 


LITERALLY 


•0E9H 




LITERALLY 


•0E8H' 




COMMANDS * 


/ 




LITERALLY 


'0 0BH' 




LITERALLY 


'0 0DH 




LITERALLY 


'00EH 




LITERALLY 


'005H 




LITERALLY 


•004H' 




LITERALLY 


•002H 




LITERALLY 


•001H' 




LITERALLY 


'006H 


, 



STATUS BITS */ 
LITERALLY '080H' 
LITERALLY •002H' 
LITERALLY '010H' 



/* DECLARATION OF ISBC 941 #0 INITIALIZATION DATA */ 
DECLARE FREQ 
DECLARE SF 

DECLARE OUTPUT$ENABLE0 
DECLARE INITIAL$STATE 
DECLARE DELAY 
DECLARE PERIOD 
DECLARE INITIAL$OUTPUT 



LITERALLY 


'0B5H 


, 


LITERALLY 


'000H' 




LITERALLY 


'001H 


, 


LITERALLY 


•000H' 




LITERALLY 


'001H 


. 


LITERALLY 


•000H' 


, 


LITERALLY 


*00EH 


, 
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/* DECLARATION OF INTERVAL TIMER PARAMETERS */ 
DECLARE PIT$0$MODE LITERALLY '016H'i 
DECLARE PIT$0$INTERVAL LITERALLY '00EHV 
DECLARE PTT$0$MODE$WRD LITERALLY '0E3HV 

DECLARE PIT$0$COUNT LITERALLY •0E0H' 

/* DECLARATION OF COUNTER LOCATIONS */ 

33 1 DECLARE (L IQ$COUNT, BELT$COUNT ) BYTE EXTERNAL; 

/* DECLARATION OF ISBC 941 PRIMARY DATA */ 

34 1 DECLARE INIT$0$TABLE ( 6 ) BYTE DATA ( 

FREQ, 

SF, 

OUTPUT$ENABLE0, 

INITIAL$STATE, 

DELAY, 

PERIOD ); 

/* DECLARATION OF MISC PARAMETERS */ 
3 5 1 DECLARE I BYTE; 

* INITIALIZATION PROGRAM BODY * 

36 1 PROCESSOR$0$INITIALIZATION: PROCEDURE PUBLIC; 

/* INITIALIZE COUNTER FOR 10 MICROSECONDS */ 
OUTPUT (PIT$0$MODE$WRD) =PIT$0$MODE; 
OUTPUT (PIT$0$COUNT)=PIT$0$ INTERVAL; 

/* VERIFY THAT PROCESSOR IS RESET */ 

DO WHILE ( (INPUT (UPI$0$STATUS) AND RFC) = 0); 

DO WHILE ( (INPUT (UPI$0$STATUS) AND IBF) <> 0); 

END; 

OUTPUT (UPI$0$COMMAND)=PACIFY; 
END; 

/* REQUEST PRIMARY FUNCTION */ 

DO WHILE ( (INPUT (UPI$0$STATUS) AND IBF) <> 0); 

END; 

OUTPUT (UPI$0$COMMAND)= INITPF; 

/* LOAD INITIAL PARAMETERS */ 
DO 1=0 TO 5; 

DO WHILE ( (INPUT (UPI$0$STATUS) AND IBF) <> 0); 

END; 

OUTPUT (UPI$0$DATA)=INIT$0$TABLE (I) ; 
END ; 

/* TERMINATE PARAMETER LOADING */ 

DO WHILE ( (INPUT(UPI$0$STATUS) AND IBF) <> 0); 

END; 

OUTPUT (UPI$0$COMMAND)=PAUSE; 
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/* START FREQUENCY FUNCTION */ 

55 2 DO WHILE (( INPUT (UPI $0$STATUS ) AND IBF) <>0); 

56 3 END; 

57 2 OUTPUT (UPI$0$COMMAND)=LOOP; 

/* SET UNUSED BITS TO ALLOW EXPANSION */ 

58 2 DO WHILE ( (INPUT (UPI$0 $STATUS ) AND IBF) <> 0); 
5 9 3 END; 

60 2 OUTPUT (UPI$0$COMMAND)=CLRP2; 

61 2 DO WHILE ( (INPUT (UPI $0$STATUS ) AND IBF) <> 0); 

62 3 END; 

63 2 OUTPUT (UPI$0$DATA)=INITIAL$OUTPUT; 

/* RETURN TO CALLING PROGRAM */ 

64 2 RETURN; 

65 2 END PROCESSOR$0$INITIALIZATION; 

$EJECT 
/***•***************************************•**** 

* THIS PROCEDURE IS USED TO INITIALIZE THE ISBC * 

* 941 PROCESSOR INSTALLED IN SOCKET 1. THE DE- * 

* VICE WILL OPERATE IN THE FCOUNT, HIGH FRE- * 

* QUENCY INPUT MODE. * 



/* DEFINE INITIALIZATION PARAMETERS */ 

DECLARE FCOUNT LITERALLY •033H' 

DECLARE INPUT$SELECT LITERALLY '001H' 

DECLARE 0UTPUT$ENABLE$1 LITERALLY •001H' 

DECLARE SAMPLING$INTERVAL LITERALLY '009H' 

DECLARE INITIAL$STATE$1 LITERALLY •0E1H* 

/* DECLARE PARAMETER INITIALIZATION TABLE */ 

71 1 DECLARE INIT$1$TABLE (4 ) BYTE DATA ( 

FCOUNT, 
INPUT$SELECT, 
0UTPUT$ENABLE$1, 
SAMPLING^INTERVAL ) ; 

* INITIALIZATION BODY * 

72 1 PR0CESS0R$1$INITIALIZATI0N: PROCEDURE PUBLIC; 

/* VERIFY THAT PROCESSOR IS RESET */ 

73 2 DO WHILE (( INPUT (UPI $1 $STATUS ) AND RFC) = 0); 

74 3 DO WHILE ( (INPUT (UPI$1$STATUS) AND IBF) <> 0); 

75 4 END; 

76 3 OUTPUT (UPI$1$C0MMAND)=PACIFY; 

77 3 END; 
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/* REQUEST PRIMARY FUNCTION */ 

DO WHILE ( (INPUT (UPI$1$STATUS) AND IBF) <> 0); 

END; 

OUTPUT (UPI$1$C0MMAND)=INITPF; 

/* LOAD INITIAL PARAMETERS */ 
DO 1=0 TO 3; 

DO WHILE ( (INPUT (UPI$1$STATUS) AND IBF) <> 0); 

END ; 

OUTPUT (UPI$1$DATA)=INIT$1$TABLE (I) ; 
END; 

/* TERMINATE PARAMETER LOADING */ 

DO WHILE ( (INPUT (UPI$1$STATUS) AND IBF) <> 0); 

END; 

OUTPUT (UPI$1$C0MMAND)=PAUSE; 

/* SET UNUSED BITS HIGH FOR SPARE ENABLES */ 

DO WHILE ( (INPUT (UPI$1$STATUS) AND IBF) <> 0); 
END ; 

OUTPUT (UPI$1$C0MMAND)=SETP1; 

DO WHILE ( (INPUT (UPI$1$STATUS) AND IBF) < <> 0); 

END ; 

OUTPUT (U PI $1$DATA)=INITIAL$STATE$1; 

/* START FREQUENCY COUNT OPERATION */ 

DO WHILE ((INPUT(UPI$1$STATUS) AND IBF) <> 0); 

END ; 

OUTPUT (U PI $ 1 $COMMAND ) =LOOP ; 
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/* RETURN TO CALLING PROGRAM */ 
RETURN; 
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END PR0CESS0R$1$INITIALIZATI0N; 
$EJECT 

* THIS PROCEDURE IS USED TO INITIALIZE THE ISBC * 

* 941 INSTALLED IN SOCKET 2. THE DEVICE WILL BE * 

* OPERATED AS A STEPPER MOTOR DRIVER. * 



/* DEFINE INITIALIZATION PARAMETERS */ 
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DECLARE STEPPER 

DECLARE SCALE$FACTOR 

DECLARE 0UTPUT$ENABLE$2 

DECLARE OUTPUT$POLARITY 

DECLARE COMMON$PERIOD 

DECLARE P20$TRAN1 

DECLARE P20$TRAN2 

DECLARE P21$TRAN1 

DECLARE P21$TRAN2 

DECLARE P22$TRAN1 

DECLARE P22$TRAN2 



LITERALLY •017H' 

LITERALLY ' 0DFH • 

LITERALLY •0F0H* 

LITERALLY •050H* 

LITERALLY '004H* 

LITERALLY •000H' 

LITERALLY '000H' 

LITERALLY •000H' 

LITERALLY •000H* 

LITERALLY •000H' 

LITERALLY '000H' 
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DECLARE 


P23$TRAN1 
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DECLARE 


P23$TRAN2 
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DECLARE 


P24$TRAN1 
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DECLARE 


P24$TRAN2 
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DECLARE 


P25$TRAN1 
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DECLARE 


P25$TRAN2 
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DECLARE 


P26$TRAN1 
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DECLARE 


P26$TRAN2 


119 




DECLARE 


P27$TRAN1 


120 




DECLARE 


P27$TRAN2 



LITERALLY 
LITERALLY 
LITERALLY 
LITERALLY 
LITERALLY 
LITERALLY 
LITERALLY 
LITERALLY 
LITERALLY 
LITERALLY 



•000H' 
•000H' 
'000H" 
'002H' 
'000H' 
'002H' 
'001H" 
'003H' 
•001H' 
•003H' 
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DECLARE CLR$LOW$PORT 



LITERALLY '00FHV 
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/* DECLARE PARAMETER INITIALIZATION TABLE */ 
DECLARE INIT$2$TABLE(21) BYTE DATA ( 
STEPPER, 
SCALE $FACTOR, 
0UTPUT$ENABLE$2, 
OUTPUT$POLARITY, 
COMMON$PERIOD, 
P20$TRAN1, 
P20$TRAN2, 
P21$TRAN1, 
P21$TRAN2, 
P22$TRAN1, 
P22$TRAN2, 
P23$TRAN1, 
P23$TRAN2, 
P24$TRAN1, 
P24$TRAN2, 
P25$TRAN1, 
P25$TRAN2, 
P26$TRAN1, 
P26$TRAN2; 
P27$TRAN1, 
P27$TRAN2 ); 

* INITIALIZATION BODY * 

************************************************/ 

PR0CESS0R$2$INITIALIZATI0N: PROCEDURE PUBLIC; 

/* VERIFY THAT PROCESSOR IS RESET */ 

DO WHILE ( (INPUT (UPI$2$STATUS) AND RFC) = 0); 

DO WHILE ( (INPUT (UPI$2$STATUS) AND IBF) <> 0); 

END; 

OUTPUT (UPI$2$C0MMAND)=PACIFY; 
END; 

/* REQUEST PRIMARY FUNCTION */ 

DO WHILE ( (INPUT (UPI$2$STATUS) AND IBF) <> 0); 

END; 

OUTPUT (UPI$ 2 $COMMAMD)=INITPF; 
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/* LOAD INITIAL PARAMETERS */ 

132 2 DO 1=0 TO 20; 

133 3 DO WHILE (( INPUT (UPI $2$STATUS ) AND IBF) <> 0); 

134 4 END; 

135 3 OUTPUT (UPI$2$DATA)=INIT$2$TABLE (I) ; 

136 3 END; 

/* TERMINATE PARAMETER LOADING */ 

137 2 DO WHILE ( ( INPUT (UPI $2 $STATUS ) AND IBF) <> 0); 

138 3 END; 

139 2 OUTPUT (UPI$2$C0MMAND)=PAUSE; 

/* START STEPPER CONTROLLER OPERATION */ 

140 2 DO WHILE (( INPUT (UPI $ 2$STATUS ) AND IBF) <> 0); 

141 3 END; 

142 2 OUTPUT (UPI$2$C0MMAND)=L00P; 

/* SET UNUSED BITS LOW TO ENABLE GENERAL FUNCTIONS */ 

143 2 DO WHILE (( INPUT (UPI $2$STATUS ) AND IBF) <> 0); 

144 3 END; 

145 2 0UTPUT(UPI$2$C0MMAND)=CLRP1; 

146 2 DO WHILE (( INPUT (UPI$2 $STATUS ) AND IBF) <> 0); 

147 3 END; 

148 2 OUTPUT (UPI$2$DATA)=CLR$L0W$P0RT; 

/* RETURN TO CALLING PROGRAM */ 

149 2 RETURN; 

150 2 END PR0CESS0R$2$INITIALIZATI0N; 

$EJECT 
/••••*•***•***•**•**•******•**•****•*******•••*** 

* THIS PROCEDURE IS USED TO INITIALIZE COUNTER * 

* 1 TO PERFORM AS AN EIGHT BIT BINARY COUNTER * 

* WHICH WILL BE USED TO MEASURE THE BELT SPEED.* 
******************•*******•**•*****************/ 

151 1 C0UNTER$1$INITIALIZATI0N: PROCEDURE PUBLIC; 

/* INITIALIZE COUNTER 1 FOR EIGHT BIT COUNTING */ 

152 2 LIQSCOUNT = 0; 

/* RETURN TO CALLING PROGRAM */ 

153 2 RETURN; 

154 2 END C0UNTER$1$INITIALIZATI0N; 

$EJECT 
/•************•*********•*************••******** 

* THIS PROCEDURE IS USED TO INITIALIZE COUNTER * 

* 2 TO PERFORM AS AN EIGHT BIT BINARY COUNTER * 

* WHICH WILL BE USED TO MEASURE THE LIQUID * 

* FLOW THROUGH THE METER. * 
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155 1 C0UNTER$2$INITIALIZATI0N: PROCEDURE PUBLIC; 

/* INITIALIZE COUNTER 2 B'OR EIGHT BIT COUNTING */ 

156 2 BELT$COUNT = ; 

/* RETURN TO CALLING PROGRAM */ 

157 2 RETURN; 

158 2 END C0UNTER$2$INITIALIZATI0N; 

159 1 END PROCESSOR$INITIALIZATION$MODULE; 

$EJECT 



MODULE INFORMATION: 

CODE AREA SIZE = 0201H 513D 
VARIABLE AREA SIZE = 0001H ID 
MAXIMUM STACK SIZE = 0000H 0D 
329 LINES READ 
PROGRAM ERROR (S) 

END OF PL/M-80 COMPILATION 
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ISIS-II PL/M-80 V3.1 COMPILATION OF MODULE PROCESSORINTERFACEMODULE 

OBJECT MODULE PLACED IN : Fl : OPR941 • OBJ 

COMPILER INVOKED BY: PLM80 : Fl: OPR94 I . PLM DEBUG 
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$INTVECTOR(4,3F00H) 

$PAGEWIDTH(72) 

$TITLE ('PROCESSOR INTERFACE') 

/********•*******************•***************** 

* THESE PROGRAMS PROVIDE THE OPERATING INTER- * 

* FACE BETWEEN THE APPLICATION PROGRAM AND * 

* THE ISBC 941 PROCESSORS OR COUNTERS. * 



PROCESSOR$INTERFACE$MODULE 
/* 



DC- 



DECLARATION OF ADDRESSES */ 
DECLARE UPI$0$STATUS LITERALLY 
DECLARE UPI$0$COMMAND LITERALLY 
DECLARE UPI$0$DATA LITERALLY 



'0E5H' 
'0E5H' 
'0E4H' 



DECLARE UPI$1$STATUS 

DECLARE UPI$1$C0MMAND 

DECLARE UPI$1$DATA 

DECLARE UPI$2$STATUS 

DECLARE UPI$2$C0MMAND 

DECLARE UPI$2$DATA 



LITERALLY •0E7H' 

LITERALLY '0E7H' 

LITERALLY '0E6H' 

LITERALLY •0E9H' 

LITERALLY !0E9H' 

LITERALLY '0E8H' 



DECLARATION OF ISBC 


941 COMMANDS * 


/ 


DECLARE 


SETPl 


LITERALLY 


'00BH'; 


DECLARE 


CLRPl 


LITERALLY 


'0 0DH'; 


DECLARE 


CLRP2 


LITERALLY 


»00EH'; 


DECLARE 


RDFC0 


LITERALLY 


'042H'; 


DECLARE 


RDFCl 


LITERALLY 


•043H'; 


DECLARE 


PAUSE 


LITERALLY 


•005H»; 


DECLARE 


LOOP 


LITERALLY 


•004H'; 


DECLARE 


INITPF 


LITERALLY 


'002H'; 


DECLARE 


PACIFY 


LITERALLY 


'001H'; 


DECLARE 


ENFLAG 


LITERALLY 


•006H'; 


DECLARE 


SETOE 


LITERALLY 


•071H'; 


DECLARATION OF ISBC 


941 STATUS BITS */ 


DECLARE 


RFC 


LITERALLY 


•080H'; 


DECLARE 


IBF 


LITERALLY 


'002H' ; 


DECLARE 


OBF 


LITERALLY 


'001H'; 


DECLARE 


QF 


LITERALLY 


'010H'; 


DECLARE 


QNE 


LITERALLY 


•020H'; 



DEFINE THE MATH ROUTINES USED BY MODULES */ 
MQULD4: PROCEDURE (IR$PTR , VALUE$PTR) EXTERNALS- 
DECLARE (IR$PTR, VALUE$PTR) ADDRESS; 
END MQULD4; 
MQUDV2: PROCEDURE (IR$PTRr VALUE$PTR) EXTERNAL; 
DECLARE (IR$PTR,VALUE$PTR) ADDRESS; 
END MQUDV2; 
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MQUDVl: PROCEDURE (IR$PTR;VALUE$PTR) EXTERNALS- 
DECLARE (IR$PTR, VALUE$PTR) ADDRESS; 
END MQUDVl; 

MQUSTl: PROCEDURE (IR$PTR, VALUE$PTR) EXTERNAL; 
DECLARE (IR$PTR,VALUE$PTR) ADDRESS; 
END MOUSTl; 

/* DEFINE THE MATH ACCUMULATOR STORAGE AREA */ 

39 1 DECLARE IR(18) BYTE EXTERNAL; 

/* DEFINE THE COUNTER LOCATIONS */ 

40 1 DECLARE (LIQ$COUNT, BELT$COUNT) BYTE EXTERNAL; 

$EJECT 
/***********************•************************ 

* THIS PROGRAM IS USED TO GENERATE A FREQUENCY * 

* OUTPUT USING THE ISBC 941 MODULE INSTALLED IN * 

* SOCKET NUMBER 0. TO PROVIDE MAXIMUM RESOLU- * 

* TION, FOUR PERIODS WILL BE USED. THE FREQUEN-* 

* CY RANGES CORRESPONDING TO EACH PERIOD ARE: * 

* RANGE FREQ RESOLUTION * 

* 1 50 TO 165 HZ 2 HZ * 

* 2 166 TO 225 HZ 3 HZ * 

* 3 226 TO 285 HZ 3 HZ * 

* 4 286 TO 550 HZ 6 HZ * 

* THE SCALE FACTOR IS COMPUTED BY THE FORMULA: * 

* SF=100000/( (FREQ)* (RANGE B'ACTOR) ) * 
********************************•***************/ 

41 1 WEIGHBELT$MOTOR$DRIVE: PROCEDURE (FREQ) PUBLIC; 

/* DECLARATION OF CONSTANT/ 100,000 */ 
4 2 2 DECLARE HUNDRED$K (4 ) BYTE DATA ( 

0A0H,086H,001H,000H ) ; 

/* DECLARATION OF ISBC941 PORT ENABLES */ 

43 2 DECLARE ENABLE$FREQ LITERALLY ' 01H ' ; 

44 2 DECLARE DISABLE$FREQ LITERALLY •00H'; 

/* DECLARATION OF ISBC 941 MEMORY LOCATION COMMANDS */ 

45 2 DECLARE WRRM$55 LITERALLY '055H'; 

46 2 DECLARE WRRM$74 LITERALLY '074H'; 

/* DECLARATION OF VARIABLES USED IN COMPUTATIONS */ 

47 2 DECLARE (RANGE, FREQA) BYTE; 

48 2 DECLARE FREQ ADDRESS; 

/* BEGIN COMPUTATION OF OUTPUT FOR FREQ > 48 HZ . */ 

49 2 IF FREQ > 49 

THEN DO; 

/* ENABLE FREQUENCY OUTPUT */ 

51 3 DO WHILE ( (INPUT (UPI$0$STATUS ) AND IBF) <> 0); 

52 4 END; 

53 3 OUTPUT (UPI$0$COMMAND) = SETOE; 
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54 3 DO WHILE ( (INPUT (UPI$0$STATUS ) AND IBF) <> 0); 

5 5 4 END; 

56 3 OUTPUT (UPI$0$DATA) = ENABLE$FREQ; 

/* COMPUTATION OF FREQUENCY RANGE */ 

57 3 IF FREQ < 285 

THEN DO; 
59 4 IF FREQ < 226 

THEN DO; 
61 5 IF FREQ < 166 

THEN RANGE = 9; 
63 5 ELSE RANGE = 5; 

6 4 5 END; 

65 4 ELSE RANGE = 3; 

66 4 END; 

67 3 ELSE RANGE = 2; 

/* LOAD MATH ACCUMULATOR WITH 10 0,000 */ 

68 3 CALL MQULD4 ( . IR, . HUNDRED$K ) ; 

/* TEST FOR MOTOR SHUTDOWN */ 

69 3 IF FREQ > 1 

THEN DO; 

/* DIVIDE BY FREQUENCY */ 

71 4 CALL MQUDV2 (.IR,.FREQ); 

/* DIVIDE BY RNAGE FACTOR */ 

72 4 CALL MQUDVl (. IR, . RANGE ) ; 

/* GET TWO'S COMPLEMENT FOR ISBC 941 SCALE FACTOR */ 

73 4 CALL MQUSTl ( . IR, . FREQA) ; 

74 4 FREQA = NOT (FREQA + 1); 

75 4 END; 

/* ADJUST FOR MOTOR STOP SIGNAL */ 

76 3 ELSE DO; 

77 4 FREQA = 00 0H; 

78 4 RANGE = 0FFH; 

79 4 END; 

/* SEND NEW SCALE FACTOR TO DEVICE */ 

80 3 DO WHILE ( (INPUT (UPI$0 $STATUS) AND IBF) <> 0); 

81 4 END; 

82 3 OUTPUT (UPI$0$COMMAND) = WRRM$55; 

83 3 DO WHILE ( (INPUT (UPI$0$STATUS ) AND IBF) <> 0); 

84 4 END; 

85 3 OUTPUT (UPI$0$DATA) = FREQA; 

/* SEND NEW PERIOD TO DEVICE */ 

86 3 DO WHILE ( (INPUT (UPI $0$STATUS ) AND IBF) <> 0); 

87 4 END; 

88 3 OUTPUT (UPI$0$COMMAND) = WRRM$74; 
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89 3 DO WHILE ( (INPUT (UPI$0$STATUS ) AND IBF) <> 0); 

9 4 END; 

91 3 OUTPUT (UPI$0$DATA) = RANGE; 

/* END OF FREQUENCY OUTPUT MODE */ 

92 3 END; 

/* HANDLE FREQUENCIES < 50 HZ . */ 

93 2 ELSE DO; 

/* DISABLE FREQUENCY OUTPUT GENERATION */ 

94 3 DO WHILE ( (INPUT (UPI $0 $STATUS ) AND IBF) <> 0); 

95 4 END; 

9^ 3 OUTPUT (UPI$0$COxMMAND) = SETOE; 

97 3 DO WHILE ( (INPUT (UPI$0$STATUS ), AND IBF) <> 0); 

98 4 END; 

99 3 OUTPUT (UPI$0$DATA) = DISABLE$FREQ; 

/* END OF ALTERNATE FREQUENCY OUTPUT */ 

100 3 END; 

/* RETURN TO CALLING PROGRAM */ 

101 2 RETURN; 

102 2 END WEIGHBELT$MOTOR$DRIVE; 

$EJECT 
/**********•******•*******•*****************•*****•*** 

* THIS PROGRAM GETS THE WEIGHBELT WEIGHT FROM THE * 

* NUMBER 1 ISBC 941 PROCESSOR. THE WEIGHT WILL BE * 

* RECEIVED AS A COUNT WHICH RANGES BETWEEN AND * 

* 2000, CORRESPONDING TO A WEIGHT BETWEEN 0.0 AND * 

* 10.00 POUNDS. EACH COUNT RECEIVED HAS A VALUE * 

* OF 0.005 POUNDS. * 
***********•*****•*•*********•*•****************••***/ 

103 1 WEIGHBELTSWEIGHT: PROCEDURE ADDRESS PUBLIC; 

/* DECLARATIONS OF VARIABLES USED IN THE PROCEDURE */ 

104 2 DECLARE (LCOUNT, HCOUNT) BYTE; 

105 2 DECLARE WEIGHT ADDRESS; 

/* GET INPUT COUNT LOW BYTE */ 

106 2 DO WHILE ((INPUT (UPI$1 $STATUS ) AND IBF) <> 0); 

107 3 END; 

108 2 OUTPUT (UPI^1$C0MMAND) = RDPCe.; 

109 2 DO WHILE ( (INPUT (UPI $1 $STATUS ) AND OBF) = 0); 

110 3 END; 

111 2 LCOUNT = INPUT (UPI$1$DATA) ; 
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/* GET INPUT COUNT HIGH BYTE */ 

112 2 DO WHILE (( INPUT (UPI $1 $STATUS ) AND IBF) <> 0); 

113 3 END; 

114 2 OUTPUT (UPI$1$C0MMAND) = RDFCt; 

115 2 DO WHILE (( INPUT (UPI $1 $STATUS ) AND OBF) = 0); 

116 3 END; 

117 2 HCOUNT = INPUT (UPI$1$DATA) ; 

/* START NEXT WEIGHT SAMPLE PERIOD */ 

118 2 DO WHILE (( INPUT (UPI $1$STATUS ) AND IBF) <> 0); 

119 3 END; 

120 2 OUTPUT (UPI$I$COMMAND) = LOOP; 

/* CONVERT WEIGHT TO AN ADDRESS VALUE */ 

121 2 WEIGHT = HCOUNT; 

122 2 WEIGHT = SHL (WEIGHT, 8 ) ; 

123 2 WEIGHT = WEIGHT + LCOUNT; 

/* DIVIDE BY TWO TO CONVERT TO POUNDS */ 

124 2 WEIGHT = SHR (WEIGHT, 1 ) ; 

/* RETURN THE WEIGHTBELT WEIGHT */ 

125 2 RETURN WEIGHT; 

126 2 END WEIGHBELT$WEIGHT; 

$EJECT 
/•************************************************* 

* THIS PROCEDURE TRANFERS THE WEIGHBELT SPEED TO * 

* THE CALLING PROGRAM AND CLEARS THE COUNTER FOR * 

* THE NEXT TEST. THE SPEED RESOLUTION PROVIDES * 

* ONLY FIVE SPEED RANGES. * 
************•*************************************/ 

127 1 WEIGHBELT$SPEED: PROCEDURE BYTE PUBLIC; 

/* DECLARATIONS OF VARIABLES USED BY THE PROCEDURE */ 

128 2 DECLARE SPEED BYTE; 

/* LATCH COUNTER BEFORE READING SPEED */ 

129 2 DISABLE; 

/* GET COUNTER VALUE FROM COUNTER */ 

130 2 SPEED = BELT$COUNT; 

/* CLEAR COUNTER FOR NEXT OPERATION */ 

131 2 BELT$COUNT = 0; 

132 2 ENABLE; 

/* RETURN DATA TO CALLING ROUTINE */ 

133 2 RETURN SPEED; 

134 2 END WEIGHBELT$SPEED; 
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$EJECT 
/*•************************************************** 

* THIS PROCEDURE PROVIDES COMMANDS TO THE STEPPER * 

* MOTOR TO OPERATE THE CONTROL VALVE. IT WILL COM-* 

* PUTE THE SIGNED MAGNITUDE REPRESENTATION FROM * 

* THE TWO'S COMPLIMENT INPUT AND WILL ISSUE THE * 

* APPROPRIATE STEP INCREMENT AND DIRECTION. A * 

* FIXED STEP RATE OF 100 STEPS PER SECOND WILL BE * 

* USED BY THE CONTROL DEVICE. * 
***************************************************/ 

135 1 LIQUID$VALVE$POSITION: PROCEDURE (POSITION) PUBLIC; 

/* DECLARATIONS OF VARIABLES USED BY THE PROCEDURE */ 

136 2 DECLARE POSITION BYTE ; 

/* DEFINITIONS OF TERMS USED IN COMPUTATIONS */ 

137 2 DECLARE STEP$RATE LITERALLY '005H'; 

138 2 DECLARE REVERSE LITERALLY '080H'; 

/* IF NO MOVEMENT, SKIP OPERATIONS */ 

139 2 IF POSITION <> 

THEN DO; 

/* SUPPORT CONVERSION TO SIGNED MAGNITUDE NUMBER */ 
141 3 IF POSITION > 127 

THEN DO; 

/* GET MAGNITUDE OF MOVEMENT */ 

143 4 POSITION = 256 - POSITION; 

/* SET SIGN FOR CCW ROTATION */ 

144 4 POSITION = POSITION OR REVERSE; 

145 4 END; 

7* VERIFY THAT QUEUE SPACE IS AVAILABLE */ 

146 3 DO WHILE ( (INPUT (UPI$2$STATUS) AND QF) <> 0); 

147 4 END; 

/* REQUEST DESIRED STEP RATE */ 

148 3 DO WHILE ( (INPUT (UPI$2$STATUS) AND IBF) <> 0); 

149 4 END; 

150 3 OUTPUT (UPI$2$DATA) = STEP$RATE; 

/* REQUEST STEPPER MOVEMENT */ 

151 3 DO WHILE ( (INPUT (UPI $2$STATUS ) AND IBF) <> 0); 

152 4 END; 

153 3 OUTPUT (UPI$2$DATA) = POSITION; 

154 3 END; 

/* RETURN TO CALLING PROGRAM */ 

155 2 RETURN; 

156 2 END LIQUID$VALVE$POSITION; 
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$EJECT 
/***•***********************•**************•***•****•* 

* THIS PROCEDURE TRANSFERS THE LIQUID FLOW RATE FROM * 

* THE FLOW COUNTER TO THE CALLING PROGRAM. AFTER * 

* READING, THE FLOW COUNTER WILL BE RESET TO FACILI- * 

* TATE THE NEXT READING. THE LIQUID FLOW COUNT WILL * 

* VARY BETWEEN 20 AND 240 PULSES IN EACH 200 MILLI- * 

* SECOND SAMPLE INTERVAL. THIS WILL CORRESPOND TO * 

* THE ACTUAL LIQUID FLOW RATE OF 10 TO 120 POUNDS * 

* PER MINUTE. * 
************•****************•*********************•*/ 

157 1 LIQUID$FLOW$RATE: PROCEDURE ADDRESS PUBLIC; 

/* DECLARATION OF VARIABLES USED BY THE PROGRAM */ 

158 2 DECLARE TEMP BYTE; 

159 2 DECLARE (FLOW/r$TWO,T$SXTN,T$THRTWO) ADDRESS; 

/* LATCH COUNTER BEFORE READING FLOW */ 

160 2 DISABLE; 

/* GET FLOW RATE VALUE FROM COUNTER */ 

161 2 TEMP = LIQ$COUNT; 

/* CLEAR COUNTER FOR NEXT OPERATION */ 

162 2 LIQ$COUNT = 0; 

163 2 ENABLE; 

/* CONVERT TO POUNDS PER MINUTE */ 

164 2 FLOW = TEMP; 

165 2 T$TWO = SHL(FL0W,1); 

166 2 T$SXTN = SHL (T$TWO, 3 ) ; 

167 2 T$T?IRTWO = SHL (T^SXTN, 1) ; 

168 2 FLOW = T$TWO + T$SXTN + T$THRTWO; 

/* RETURN FLOW RATE TO CALLING PROGRAM */ 

169 2 RETURN FLOW; 

170 2 END LIQUID$FLOW$RATE; 

$EJECT 
/******************************************** 

* COUNTER FOR LIQUID FLOW RATE FROM LIQUID * 

* FLOW METER. COUNT PULSE WILL GENERATE AN * 

* INTERRUPT AT LEVEL 1. * 
********************•****************•******/ 

171 1 LIQ$CNT: PROCEDURE INTERRUPT 1 PUBLIC; 

/* INCREMENT FLOW COUNT */ 

172 2 LIQ$COUNT = LIQ$COUNT + 1; 

/* SEND END OF INTERRUPT */ 

173 2 OUTPUT (0ECH) = 020H; 
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/* RETURN */ 
174 2 RETURNS- 

ITS 2 END LIQ$CNT; 

$EJECT 
/*•*************•*•*****•******************** 

* THIS PROCEDURE WILL PROVIDE AN EVENT COUN-* 

* TER TO HANDLE THE BELT MOTION DETECTOR. * 

* IT WILL OPERATE BY DIRECTING THE MOTION * 

* PULSE TO INTERRUPT 2. * 
********************************************/ 

176 1 BELT$CNT: PROCEDURE INTERRUPT PUBLIC; 

/* INCREMENT BELT MOVEMENT */ 

177 2 BELT$COUNT = BELT$COUNT + 1; 

/* SEND END OF INTERRUPT */ 

178 2 OUTPUT (0ECH) = 020H; 

/* RETURN */ 

179 2 RETURN; 

180 2 END BELT$CNT; 

181 1 END PROCESSOR$INTERFACE$MODULE; 



MODULE INFORMATION: 

CODE AREA SIZE = 0251H 593D 
VARIABLE AREA SIZE = 0013H 19D 
MAXIMUM STACK SIZE = 0008H 8D 
400 LINES READ 
PROGRAM ERROR (S) 

END OF PL/M-80 COMPILATION 
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Designing and Assembling 
l\/licrocomputer Systems Grows Easier 

Although a single data bus stantdard yet eludes the microcomputer industry, numer- 
ous manufacturers of single-board computer and supplementary boards have cast a 
hardware vote for the Multibus. Intel's microcomputer backplane which they origina- 
ted in 1976. With a steady eye on the control industry market, Intel has designed a 
home to accommodate Multibus compatible equipment, the iCS-80 industrial chas- 
sis. It promises to significantly reduce the time and cost of assembling the housing 
and interface parts of a microcomputer-based control system. In this article, besides 
taking the first look at Intel's new chassis and signal conditioning panels, we've put 
together a comprehensive list of Multibus compatible equipment. 



MICHAEL J. McGOWAN, Control Engineering 



After the development of single-board 
computers nearly three years ago, ven- 
dors moved quickly to seize a fraction of 
the market. It seemed at first that every- 
thing from memories to analog I/O 
boards had become available. With an 
astonishing suddenness, companies 
sprang up in Silicon Valley, Texas, New 
Jersey, and along the forested roadside 
of Rt. 128 outside of Boston. Late that 
year, we counted well over a hundred 
companies anxious to make their for- 
tune selling the control engineer every- 
thing from one or two interface boards 
to complete microprocessor systems. 

Then the pleasant dream became a 
nightmare. From power supply require- 
ments to backplane pinouts. little was 
compatible. Even such an obvious thing 
as board size differed from vendor to 
vendor and many a hope for an ideal 
system was crushed in a pragmatic 
search for whatever would fit together. 

Seven months ago in our June 1978 
issue we noted that the number of mi- 
crocomputer system manufacturers 
had dwindled to about 60 and since 
then, we find still fewer. Some, no doubt, 
were forced out for lack of reliability, 
though most, despite remarkably ta- 
lented engineering, starved as the mar- 
ket saturated. 

Large scale integration of microcom- 
puter components has more than 
doubled the memory size of single- 
board computers. Sixteen bit word 
lengths will become commonplace in 
the next year as microcomputer perfor- 
mance begins to rival the mini- 
computer's and the lines of distinc- 
tion between micros and minis fades. 

The fight for a standard data bus 
drags on with leaders in the struggle but 
no winner. On the offensive. Pro-Log 
and Mostek jointly introduced the STD 
bus last autumn in an attempt to gain a 
greater market share by espousing de- 
centralized system architectures. Their 
philosophy argues economics: the user 
should pay only for essential functions 
by selecting small, specialized boards 



and not squander funds on a general 
purpose board with extra features. 

Still. Intel, favoring more densely 
packed and versatile boards, continues 
to dominate the market while the Multi- 
bus retains its popularity. Today more 
30 manufacturers produce over one 
hundred different boards based on that 
bus structure alone. Not that Intel enjoys 
the strict fidelity of its outside vendors; 
Digital Equipment Corporation, for in- 
stance, boasts some 17 companies 
providing boards to mate with the 
LSI-11 and LSI-112. 



But perhaps alone among its compet- 
itors. Intel has recognized that the ma- 
jority of its boards are being used in 
industrial applications and that the con- 
trol system designer needs more than 
components. 

An industrial chassis 

A microcomputer system designer must 
choose components that are electro- 
mechanically compatible. To that end, 
Intel is introducing the iCS-80 industrial 
chassis and termination panels. It 
makes all Multibus-compatible CPU 
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MULTIBUS Compatible 
Boards and Vendors 


Analog Input and 
Output Boards 
Analog Signal Conditioning/ 
Screw Terminations 

Communications Boards 


Core Memory Boards 
Digital Input/Output Boards 
Digital Relay Boards 


CPU Boards 

DMA Controller Boards 

Floppy Disk 
Controller Boards 


Hard Disk Interface Boards 

IEEE-488 Bus 

Interface Boards 

Keyboard Controller Boards 


Math Boards 

Optical Isolator Boards 
(without screw terminations) 

Optical Isolation With 
Screw Terminations 


PROM Boards 
RAM Boards 
RAM/PROM or ROM 
Synchro to Digital Boards 


Tape (cartridge/cassette) 
Interface Boards 

Tape (72") Interface Boards 

Video Boards 

Wire Wrap Boards 


ADAC Corp. 


• 














Advanced Micro Computers 






• 




• 






Ampex 




• 












Analog Devices 


• 














Augat 














• 


Burr-Brown 


• 


• 












Computer Marketing 


e 




• 


• 




• 


• • • 


Data Translation 


• 














Datacube 












• • • 


• 


Datel Systems 


• 














Electronic Solutions 












• • 




Garry Manufacturing 














• 


HT Instruments 














• 


Hal Communications 














• 


Heurikon 


• 




• • 






• • 


• • 


IDEAS 


• 




• 


• 


• 


• 




Intel 


• • • 


• 


* • • 


• 


• • • 


• • • 


• 


Interphase 


• 




• 


• 






• 


Matrox Electronic Systems 














• 


Megalogic 












• • • 


• 


Micro Memories 
















Micro Networks 


• 


• 












MicroTec 
















Micro/Tel 
















Monolithic Systems 






• • 






• 


• 


Motorola 












• 




MUPRO 












• 




National Semiconductor 


• • 


• 


• • • 


• 


• 


• • • 


• • 


North Star Computers 










• 






Pertec (ICOM) 
















Relational Memory Systems 






• 










Systems, Computers and Interfaces 






• • 


• 




• • 


• 


Thomas Engineering Co. 
















Vector Electronic 














• 


XEDAX 








• 






• 


ZIA Tech 








• 
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and peripheral boards readily usable. 

The advantage of the ICS-80 is that 
most of the interconnection and me- 
chanical details for assembling a 
microcomputer-based control system 
have already been worked out. 

The iCS-80 stands 15.75 inches high 
and can be mounted in a stardard 
RETMA 1 9 inch rack, or in a NEMA cabi- 
net secure from the industrial environ- 
ment. The minimum layout consists of a 
four-slot Multibus card cage with provi- 
sions for adding two more cages to a 
maximum of twelve cards. The cages fit 
vertically, like records in a rack, to aid 
convection cooling and permit front ac- 
cess for insertion and maintenance. 

On the right side of the chassis is 
room for either a 1 4 or 30 ampere power 
supply, the choice dictated by the ap- 
plication The system will operate on 
either 11 5 or 230 volts with a range of 47 
to 63 Hertz specified in anticipation of 
international service. 

Cooling is assisted by four fans — 
three for the card cages and one for the 
power supply section. The intention 
here is to make the installation of addi- 
tional fans unnecessary even after the 
system has expanded. The fans are ex- 
pected to provide adequate cooling for 
most applications so supplementary air 
conditioning can be eliminated or at 
least minimized. 

Signal conditioniiig 

Three signal conditioning panels have 
been developed by Intel to simplify con- 
nections between the processing cards 
and the outside world. The principle is 
neatness, and with that follows reliabil- 
ity. Flat ribbon cables connect the sig- 
nal conditioners to the processor cards, 
a safeguard from "which wire is which" 
and screwdriver slips in the vicinity of 
expensive boards. Field connections to 
the external inputs and outputs are 
made (presumably by electricians with 
big hands and reputations for being 
less than delicate) through rugged, 
screw-type barrier strips that accept 
wire as heavy as 14 AWG. The panels 
can mount either on RETMA cabinet 
brackets, NEMA wall spacers, or on the 
iCS-80 chassis itself. 

Each signal conditioning card gives 
the user a variety of options. The iCS-910 
analog signal conditioning/termination 
panel accepts up to 1 6 differential or 32 
single ended input channels. The four 
2-wire analog output channels might be 
connected to 4 to 20 mA current loops. 

The digital signal conditioning termi- 
nation panel, iCS-920, handles 24 two- 
wire input or output channels with sig- 
nals up to 55 V, 300 mA. Inputs can be 
diode protected, and pads are pro- 
vided for current limiters or voltage di- 
viders. Optoisolators may be inserted in 



Vendors of Multlcompatible Boards 




ADAC Corp. 


Matrox Electronic Systems 


Woburn. MA 


Montreal, Quebec 


617/935-6668 


514/735-1182 


Advanced Micro Computers 


Megalogic 


Santa Clara, CA 


Brookville, OH 


408/732-2400 


513/833-5222 


Ampex 


Micro Memories 


El Segundo, CA 


Chatsworth. CA 


714/973-2970 


213/998-0070 


Analog Devices 


Micro Networks 


Norwood. MA 


Worcester, MA 


61 7/329-4700 


617/852-5400 


Augat 


MicroTec 


Attleboro. MA 


Sunnyvale, CA 


617/222-2202 


408/733-2919 


Burr-Brown 


Micro/Tel 


Tucson, AZ 


St. Louis, MO 


602/655-8000 


314/569-3450 


Computer Marketing 


Monolithic Systems 


Waltham, MA 


Englewood, CO 


617/894-7000 


303/770-7400 


Data Translation 


Motorola 


Natick, MA 


Austin, TX 


617/655-5300 


512/928-6572 


Datacube 


MUPRO 


Reading, MA 


Sunnyvale, CA 


61 7/944-4600 


408/737-0500 


Datel Systems 


National Semiconductor 


Canton, MA 


Santa Clara, CA 


617/828-8000 


408/737-5262 


Electronic Solutions 


North Star Computers 


San Diego, CA 


Berkeley, CA 


714/292-0242 


415/549-0858 


Garry Manufacturing 


Pertec (ICOM) 


New Brunswick, NJ 


Chatsworth, CA 


212/267-6844 


213/998-1800 


HT Instruments 


Relational Memory Systems 


Marina Del Rey, CA 


San Jose. CA 


312/822-4296 


408/248-6356 


Hal Communications 


Systems, Computers and Interfaces 


Urbana, IL 


Waltham, MA 


217/367-7373 


617/899-2359 


Heurikon 


Thomas Engineering Co, 


Madison. Wl 


Concord, CA 


608/255-9075 


415/686-3041 


ID5AS 


Vector Electronic 


eeltsville, MD 


Sylmar, CA 


301/937-3600 


213/365-9661 


Intel 


XEDAX 


Aloha, OR 


Alameda. CA 


503/642-2563 


415/521-6600 


Interphase 


ZIA Tech 


Dallas, TX 


Cupertino, CA 


214/238-0971 


408/996-7082 



the DIP sockets for high voltage isola- 
tion or jumpers may be used instead 
when the input is TTL. Similarly, output 
sockets accept jumpers for direct TTL 
output, DIP optoisolators for transient 
suppression, or integrated circuit (open 
collector) drivers for high voltage- to 
high current outputs. Activity on each 
channel is indicated by LEDs. 

The ac signal conditioning/(solidas) 
termination panel, iCS-930, will actually 
work with ac or do on its 16 channels. 
The user supplies optoisolators for input 
isolation and optically-isolated solid 



state relays for output isolation. Mount- 
ing pads for customer-supplied MOVs 
or snubber networks are included. As 
before, a fuse gives overload protection 
and LEDs indicate channel activity. 

The advantage of all this is that by 
plugging in some components and per- 
haps inserting a few resistors and capa- 
citors, the interface units can be tailored 
to a particular application. Since many 
mechanical and electrical connection 
problems have already been solved, a 
customized unit can be built with mini- 
mum effort. □ 
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DOCUMENTATION 



RELATED INTEL PUBLICATIONS 

System 80/10 Microcomputer Hardware Reference Manual, 98-00316B 

iSBC 80/10 and iSBC 80/10A Single Board Computer Hardware Reference Manual, 9800230F 

ISBC 80P and iSBC 80P10 Prototyping Package User's Guide, 9800223D 

iSBC 80/20 and ISBC 80/20-4 Single Board Computer Hardware Reference Manual, 98-31 7C 

ISBC 80/30 Hardware Reference Manual, 9800611 A 

ISBC 86/12 Single Board Computer Hardware Reference Manual, 9800645A 

ISBC 544 Intelligent Communications Controller Board Hardware Reference Manual, 9800616B 

ISBC 569 Intelligent Digital Controller Board Hardware Reference Manual, 9800845 

iSBC 941 Industrial Digital Processor User's Guide, 9803077-02 

iCS 80 Industrial Chassis Hardware Reference Manual, 9800799A 

iSBC 310 High Speed Mathematics Unit Hardware Reference Manual, 9800410A 

iSBC 957 Intellec-iSBC 86/12 Interface and Execution Package User's Guide, 9800743A 

Intel MULTIBUS Specification, 9800683 

MCS-80 User's Manual, 98-153D 

MCS-85 User's Manual, 98-366C 

The 8086 Family User's Manual 

UPI-41 User's Manual, 9800504 

Introduction to the UPI-41 A, AP-41 

RMX/80 User's Guide, 9800522C 

ISIS-II User's Guide, 9800306D 

8080/8085 Assembly Language Programming Manual, 9800301 C 

PL/M-80 Programming Manual, 9800268B 

ISIS-II PL/M-80 Compiler Operator's Manual, 9800300 

FORTRAN-80 Programming Manual, 9800481 A 

ISIS-II FORTRAN-80 Compiler Operator's Manual, 9800480B 

"How to use FORTRAN with other Intel Languages", AP-44 

BASIC-80 Reference Manual, 9800758 

A Guide to Intellec Microcomputer Development Systems by Daniel D. McCracken, 9800558B 

8080/8085 Fundamental Support Package (FSP) Reference and Operating Instructions for ISIS-II Users, 9800887-01 

8086 Assembly Language Reference Manual, 9800640A 

MCS-86 Assembler Operator's Instructions for ISIS-II Users, 9800641 A 

PL/M-86 Programming Manual, 9800466A 

ISIS-II PL/M-86 Compiler Operator's Manual, 9800478A 

ISIS-II 8086 Cross Development Utilities Operator's Manual, 9800639A 
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Title 



Part No. 



MEMORY COMPONENTS 

Memory Design Handbook — 1979 

Growing Static RAM Family Album 

2115A/2125A Brochure 

RR 7 - 2107A/2107B Reliability 

RR 8 — Polysilicon fuse Bipolar PROM 

RR 11 — 2416 16K CCD Memory 

RR 12 - 2708 8K Erasable PROM 

RR 14 — 2115/2125 MOS Static RAMS 

RR 15 - 2104A 

RR 16 — 2116 

RR 18 — HMOS Reliability Update 

RR 19-2716 - UV Erasable PROM 

RR 20-2117— Reliabllty 

AR20— 16KRAM 

AR 35-2716 — Erasable PROM-16,384 Bits On-Chip 

AR 44 — Speedy RAM Runs Cool — 2147 

AR 46 — HMOS Scales Traditional Devices 

AR 78 — ISSCC Reprint on Static RAMS 

AP 22 - Which Way for 16K 

AP23-2104A4KRAM 

AP 30 - Appjications of 5 Volt EPROM & ROM Family 

AP 46 — Error Detecting and Correcting Codes 



011100 
010100 
001710 
006540 
006560 
006700 
006720 
006740 
006750 
006760 
006771 
006775 
006780 
006900 
007300 
007320 
007330 
007370 
008300 
008500 
008550 
008560 



TELECOM 

AR 79 - ISSCC Reprint - 2920 

AR 80 - ISSCC Reprint — 2912 

AR 81 — Single Chip NMOS Micro-process Signals 

AR 88 — First Monolithic PCM Filter 



007375 
007380 
007385 
007400 



MAGNETICS 

Bubble Memory Design Handbook 

AR 92 — Megabit Bubble Memory Chip Gets Support from LSI 

AR 96 — Here Comes A Million Bit Chip 

A Total System Solution to Magnetics Applications (Technical Paper) 



900020 
900500 
900515 
900520 



MICROCOMPUTER COMPONENTS 

MCS 48 User's Manual 

MCS 48 Product Description (98-615) 

MCS 48 Applications Handbook 

MCS 48 Reference Card (98-412) 

AP 24 - MCS 48 Family (98-413) 

AP 40 — Keyboard/Display Scanning . . . MCS 48 (98-755) 

AP 49 — Serial I/O and Math Utilities . . . 8049 (98-904) 

AP 55A — High Speed Emulator for MCS 48 

AP 56 — Designing With Intel's 8022 Micro (98-954) 

AR 58 — Microcontroller Includes A-D Converter (98-718) 

AR 63 — Microcomputer's On-Chip Functions — 8022 (98-780) 

AR 102 —Designing Reliable Software for Auto Applications 

AR 107 — Use EPROM 1-Chip ;tCs as Effective 1-Shot Lab Aids 

UPI-41 User's Manual 

UPI-41 Reference Card (98-671) 

MCS-48 and UPI-41 Assembly Language Programming Manual 

MCS-80 User's Manual 

RR 10 — 8080/8080A Microcomputer 

MCS-85 User's Manual 

MCS-85 Product Description (98-365) 

8080/8085 Reference Card (98-438) 

AP 29 — Using the Intel 8085 Serial I/O Lines (98-684) 

8080/8085 Assembly Language Programming Manual 

8080/8085 Floating Point Arithmetic Library User's Manual 



98-270 
201710 
121511 
202300 
203800 
203805 
203810 
203815 
203820 
203605 
203610 
207350 
207355 
98-504 
203100 
98-255 
98-153 
207100 
98-366 
205770 
205785 
207715 
98-940 
98-452 
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Part No. 



MCS-8e User's Manual 

MCS-86 Product Description (98-723) 

AR 74 — Get Minicomputer Features at 10 x Speed with 8086 (98-921) 

AR 82 — CPU Brings 6-Bit Performance (98-957) 

AP 50 — Debug Strategies for 8089 

AP 51 — Design 8086/8088/8089 with 8289 

MCS-86 Assembly Macro Language Reference Manual 

MCS-86 Assembly Language Reference Guide (98-749) 

Peripheral Design Handbook 

Peripherals Product Description 

Microcomputers and Peripherals Pocket Guide (98-843) 

AR 53 — Micro Interfacing Characteristics (8253) — (98-647) 

AR 89 — Powerful I/O Processor Unloads CPU (8089) 

AP 15 — 8255 Programmable Peripheral Interface (98-333) 

AP 16 — Using the 8251 (98-334) 

AP 31 - Using the 8259 (98-658) 

AP 32 — 8275 and 8279 (98-576) 

AP 35 — Crystals Specifications (98-652) 

AP 45 — Using the 8202 Dynamic RAM Controller (98-809) 

AP 48 — Direct Memory Access w/8257 DMA Controller 

AP 54 — Dot Matrix Printer Controller Using the 8295 (98-816) 

AP 59 — Using 8259A Programmable Interrupt Controller 



98-722 
205880 
207310 
207320 
207755 
207760 
98-640 
205900 
98-676 
205600 
205615 
207305 
207330 
207700 
207705 
207720 
207725 
207730 
207745 
207750 
207765 
207770 



INDUSTRIAL GRADE PRODUCTS 

Industrial Environment Brochure 
Industrial Grade Product Book 



206000 
206005 



MILITARY COMPONENTS 

Military Products Data Catalog 



004150 



GENERAL DATA CATALOGS 

1979 Components Data Catalog 
1979 Systems Data Catalog 



010200 
506000 



PROTOTYPE MICROCOMPUTER KITS 

SDK-85 User's Manual 
SDK-86 Assembly Manual 
SDK-86 User's Guide 



98-451 
98-697 
98-698 



ICS INDUSTRIAL CONTROL SERIES 

iCS 920 Digital Signal Hardware Reference Manual 

iCS 80 Industrial System Site Planning Guide 

ICS 80 Industrial Chassis Hardware Reference Manual 

iSBC 711 Analog Input Board Reference Manual 

iSBC 724 Analog Output Board Reference Manual 

iSBC 732 Combination Analog Input/Output Board Hardware Reference Manual 

iSBC 941 Industrial Digital Processor User's Guide 

iCS Product Description (881-02) 

iCS Brochure 

AP 52 — Intel's Industrial Control Series In Control Applications (98-932) 



98-801 
98-798 
98-799 
98-485 
98-486 
98-487 
98-3077 
500115 
500110 
511040 



SYSTEMS SOFTWARE 

RMX/80 User's Guide 

AP33- RMX/80 (98-577) 

AP 47 — Using FORTRAN-80 for iSBC Applications (98-836) 



98-522 
511020 
452015 



OEM MICROCOMPUTER SYSTEMS 

ISBC 80/04 Hardware Reference Manual 
iSBC 80/05 Hardware Reference Manual 
ISBC 80/10 and iSBC 80/1 OA Hardware Reference Manual 



98-482 
98-483 
98-230 
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AP 26 - iSBC 80/10-System 80/10 

RR 17 - iSBC 80/10 Reliability 

ISBC 80/20 and iSBC 80/20A Hardware Reference Manual 

AR 28 — Control Engineering ISBC 80/20 Description 

ISBC 80/30 Hardware Reference Manual 

AR 65 — Triple Bus Architecture (ISBC 80/30) 

iSBC 957 Intellec iSBC 86/12 User's Guide 

AP 43 - Using the iSBC 957 (98-816) 

ISBC 86/12 Hardware Reference Manual 

AR 72 — 16-Bit Single Board Computer 

AR 69 - Dual-Port RAM Hikes Throughput (iSBC 80/30) 

ISBC 016 16K RAM Expansion Board Hardware Reference Manual 

iSBC 032/048/064 Random Access Memory Boards Hardware Reference Manual 

ISBC 094 4K-Byte CMOS RAM/Battery Backup Board Hardware Reference Manual 

ISBC 104/108/116 Combination Memory and I/O Expansion Boards Hardware Reference Manual 

iSBC 202 Double Density Diskette Controller Hardware Reference Manual 

iSBC 204 Flexible Disk Hardware Reference Manual 

iSBC 206 Disk Controller Hardware Reference Manual 

iSBC 310 High-Speed Mathematics Unit Hardware Reference Manual 

ISBC 416 16K PROM/ROM Expansion Board Hardware Reference Manual 

ISBC 464 PROM/ROM Board Hardware Reference Manual 

ISBC 501 Direct Memory Access Controller Hardware Reference Manual 

ISBC 508 I/O Expansion Board Hardware Reference Manual 

ISBC 517 Combination I/O Expansion Board Hardware Reference Manual 

ISBC 519 Programmable I/O Expansion Board Hardware Reference Manual 

ISBC 534 Four-Port Communications Expansion Board Hardware Reference Manual 

iSBC 544 Intelligent Communications Controller Board Hardware Reference Manual 

ISBC 556 Optically Isolated Programmable I/O Board Hardware Reference Manual 

iSBC 569 Intelligent Digital Controller Hardware Reference Manual 

iSBC 604/614 Cardcage Hardware Reference Manual 

iSBC 635 Power Supply User's Manual 

ISBC 640 Power Supply Hardware Reference Manual 

iSBC 660 System Chassis Hardware Reference Manual 

ISBC 915 GO-NO-GO Diskette Diagnostic and Monitor Program User's Manual 

System 80/10 Microcomputer Hardware Reference Manual 

System 80/20-4 Microcomputer Hardware Reference Manual 

System 80/30 User's Guide 

AR 48 — Reduce your Micro-based system design time 

AR 55 — Design Motivations for Multiple Processor Micro Systems 

AR 64 — Microcomputers — Single Chip or Single Board 

AP 28A - MULTIBUS Interfacing (98-587) 

Intel Delivers 8-bit/16-bit BM Configuration Envelopes 



511000 
509000 
98-317 
510100 
98-611 
510140 
98-743 
511030 
98-3075 
510160 
510150 
98-279 
98-488 
98-449 
98-277 
98-420 
98-568 
98-567 
98-410 
98-265 
98-643 
98-294 
98-278 
98-388 
98-385 
98-450 
98-616 
98-489 
98-845 
98-708 
98-298 
98-803 
98-505 
98-350 
98-316 
98-484 
98-710 
510110 
510120 
510130 
511010 
501100 



INTELLEC MICROCOMPUTER DEVELOPMENT SYSTEM 

Intellec 800 Operator's Manual 

Intellec Reference Manual 

Intellec Diagnostic Confidence Test Operator's Manual 

Intellec Double Density DOS Hardware Reference Manual 

ISIS I DOS Operator's Manual 

Diskette Operating System Manual 

Paper Tape Reader Guide 

Series II Hardware Reference Manual 

Series II Model 210 User's Guide 

Intellec Series II Functional Description and Specifications (98-606) 

Intellec Series II Installation and Service Manual 

Intellec Series Hardware Interface Manual 

Success Manual for Single-Chip Microcomputer Users 

Success Manual for 8086 Users 

Microcomputer Development Package Booklet 

AR 97 — Minimizing Risk Through Use of Micro Development Systems 



98-129 
98-132 
98-386 
98-422 
98-206 
98-212 
98-016 
98-556 
98-557 
404010 
98-559 
98-555 
402050 
402100 
404000 
451130 
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Title Part No. 

SOFTWARE 

iCIS Cobol Language Reference Manual 98-927 

iCIS Cobol Packet Reference Card (98-929) 409100 

2920 Assembly Language Manual 98-987 

2920 Simulator User's Guide 98-988 

FORTRAN-80 Programming Manual 98-481 

FORTRAN-80 Reference Card (98-547) 400600 

AR 73 -- 8080 gets a "full blown" FORTRAN (98-844) 451125 

PUM Programming Manual 98-268 

AR 59 — Modular Programming in PUM 451115 

PUM 86 Programming Manual 98-466 

BASIC-80 Reference Manual 98-758 

BASIC-80 Reference Guide (98-774) 400705 

AR 61 — Microprocessor Software Development Tools 451120 

AR 98 — Software Development Package for 8086 System Designers 451135 

ISIS II FORTRAN-80 Compiler Operator's Manual 98-480 

ISIS II PUM Compiler Operator's Manual 98-300 

ISIS II PUM 86 Compiler Operator's Manual 98-478 

ISIS II 8085 Macro Assembler Operator's Manual 98-292 

ISIS II System User's Guide 98-306 

ISIS II Reference Card (98-841) 403350 

ISIS II CREDIT User's Guide 98-902 

CREDIT CRT-Based Text Editor Pocket Reference (98-903) 407700 

MCS-86 Assembly Language Converter Operating Instructions for ISIS II Users 98-642 

MCS-86 Assembly Operation Instructions for ISIS II Users 98-641 

MCS-86 Software Development Utilities Operating Instructions for ISIS II Users 98-639 

ICE-86 Operating Instructions for ISIS II Users 98-714 

ICE-49 Operating Instructions for ISIS II Users 98-632 

Multi-ICE Operating Instructions for ISIS II Users 98-672 

iCIS-COBOL Compiler Operator's Instructions for ISIS II Users 98-928 

8089 Assembler User's Manual 98-938 

EMULATORS 

ICE-30 Reference Manual 98-220 

ICE-41 Operator's Manual 98-465 

ICE-41 Reference Card (98-766) 305075 

ICE-48 Operator's Manual 98-464 

MCS-48 ICE Reference Card (98-653) 303925 

ICE-80 Reference Manual 98-167 

ICE-80 Operator's Manual 98-185 

ICE-85 Operating Instructions 98-463 

ICE-85 Brochure 406215 

ICE-86 Pocket Reference (98-838) 406310 

Multi-ICE Reference Card (98-810) 406505 

PROM PROGRAMMERS 

Universal PROM Programmer User's Manual 98-819 

Universal PROM Programmer Reference Manual 98-133 

PROMPT 

PROMPT 48 Microcomputer User's Manual 98-402 

PROMPT 48 Reference Card (98-404) 304850 

PROMPT 80/85 User's Manual 98-307 

/iSCOPE 

/iScope 820 Operator's Handbook 98-526 

/iScope Reference Card (98-582) 408150 

/tScope 8080A Probe Service Manual 98-592 

^iScope 8085 Probe Service Manual 98-728 

/iScope Console Service Manual 98-593 
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Title Part No. 

//Scope 820 Micro-Console Key Sequence Guide 98-826 

AP 42 — Writing Diagnostics for the //Scope (98-753) 452005 

ADD'IN/ADD-ON MEMORY SYSTEMS 

in-7000/in-7001 Product Description 888200 

in-1670 Product Description 888210 

in-4011 Product Description 888220 

ln-6034 Product Description 888230 

Series 90 Product Description — Cl\/190 888240 

Series 90 Product Description — CM92 888250 

Series 90 Configuration Guide 888790 

AP 63 — Control and Interleaving BXP Standard Memory Bus 888510 
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